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(57) 153 An automated banking machine (12) is operative to conduct transactions in response to HTML documents 
and TCP/IP messages exchanged with a local computer system (14) through an intranet (16), as well as in response to 
messages exchanged with foreign servers (20, 22, 24, 26, 28, 96) in a wide area network (18). The banking machine 
includes a computer (34) having an HTML document handling portion (76, 80, 82). The HTML document handling 
portion is operative to communicate through a proxy server (88), with a home HTTP server (90) in the intranet or the 
foreign servers in the wide area network. The computer further includes a device application portion (84) which 
interfaces with the HTML document handling portion and dispatches messages to operate devices (36) in the 
automated banking machine. The devices include a sheet dispenser mechanism (42) which dispenses currency as well 
as other transaction devices. The device application portion communicates with a device interfacing software portion 
(64) in the banking machine through a device server (92) in the intranet. The device server maintains local control over 
the devices in the banking machine including the sheet dispenser. The banking machine operates to read indicia on the 
user's card corresponding to a system address. The computer is operative to connect the banking machine to the home 
or foreign server corresponding to the system address, which connected server operates the banking machine imtil the 
completion of transactions by the user. 
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TBCIINICAL FIELD 

This invention rclalcs to aulonuilcd banking machines. Specifically 
Ihis invcniion relates to an automated banking machine apparatus and system 
that is capable ol use in a wide area network, which provides a liser with a 
familiar interface from their home institution at Ivanking machines operated by 
other institutions, and which provides greater options for machine outputs. 

BACKGROUND ART 

Automated banking machines are well known. A common type of 
automated banking machine used by consumers is an automated teller machine 
("ATM"). ATMs enable customers to carry out banking transactions. 
Common banking transactions that may be carried out with ATMs include the 
dispensing of cash, the making of deposits, the transfer of funds between 
accounts, the payment of bills and account balance inquiries. The type of 
banking transactions a customer can carry out are determined by capabilities 
of the particular banking machine and the programming of the institution 
operating the machine. Other types of automated banking machines may 
allow customers to charge against accounts or to transfer funds. Other types 
of automated banking machines may print or dispense items of value such as 
coupons, tickets, wagering slips, vouchers, checks, food stamps, money 
orders, scrip or travelers checks. For purposes of this disclosure an automated 
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bunking machine or automated transaction machine shall encompass any 
device whicli cairies out transactions inchuitng transrers oPvahie. 

Currently ATMs arc operated in proprietary comnuuiications networks. 
These networks interconnect ATMs operated by financial institutions and 
5 other entities. The interconnection of the networks oden enables a user to use 
a banking machine operated by another institution iTthe 
Toreign institution's banking machine is interconnected with the network that 
includes the user's institution. However when the customer operates the 
Toreign institution's machine the customer must operate the machine using the 

10 customer interface that has been established by the foreign institution for its 
banking machines. In addition the user is limited to the transaction options 
provided by the foreign institution. 

A customer may encounter difficulties when using a foreign 
institution's machine. Problems may occur because the user is not familiar 

1 5 with the type of machine operated by the foreign institution. Confusion may 
result because the customer does not know which buttons or other mechanisms 
to actuate to accomplish the desired transactions. The transaction flow for a 
customer at a foreign institution machine may be significantly different from 
machines operated by the user's home institution. This may be particularly a 

20 problem when the user is from another country and is not familiar with the 
type of banking machine or the language of the interface provided by the 
foreign institution. Likewise, the documents which are printed by printers in 
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an automalcd bunking machine arc generally limited to a limited group or 
defined Tomiats in u single language. 

A foreign institution may also provide different ty|ies of transactions 
than the user is familiar with at their home institution. For example the user's 
home institution may enable the transfer of funds between accounts through 
their automated banking machines, to enable the user to maintain funds in 
higher interest bearing accounts until they are needed. If the foreign 

institution does not provide this capability, the user will be unable to do this 
when operating the foreign machine. Tlie inability of a user at a foreign 
machine to conduct the transactions that they are accustomed to may present 
problems. 

The networks that operate automated teller machines and other types of 
automated banking machines generally operate proprietary networks to which 
access is restricted. This is necessary to prevent fraud or tampering with the 
network or user's accounts. Proprietary networks are also generally used for 
the transmission of credit card messages and other financial transaction 
messages. Access to such credit card processing systems is also restricted 
primarily for purposes of maintaining security. 

Communication over wide area networks enables messages to be 
communicated between distant locations. The best known wide area network 
is the Internet which can be used to provide communication between 
computers throughout the world. The Internet is not widely used for financial 
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Iransaclion messages because it is nol a secure system. Messages inteiulctl for 
receipt at a particular computer address may be intercepted at other addresses 
without detection. Because the messages may be intercepted at locations that 
are distant in the world from the intended recipient, there is potential for fraud 
and corruption. 

Companies are beginning to provide approaches for more secure 
transmission of messages on the Internet. Encryption techniques are also 
being applied to Internet messages. However the openness of the Internet has 
limited its usefulness for purposes of financial messages, particularly financial 
messages associated with the operation of automated banking machines. 

Messages in wide area networks may be communicated using the 
Transmission Control Protocol/Internet protocol ('TCP/IP"). U.S. Patent No. 
5,706,422 shows an example of a system in which financial information stored 
in databases is accessed through a private wide area network using TCP/IP 
messages. The messages transmitted in such networks which use TCP/IP may 
include "documents" (also called "pages"). Such documents are produced in 
Hypertext Markup Language ("HTML") which is a reference to a type of 
programming language used to produce documents with commands or 'tags" 
therein. The tags are codes which define features and/or operations of the 
document such as fonts, layout, imbedded graphics and hypertext links. 
HTML documents are processed or read through use of a computer program 
referred to as a "browser". The tags tell the browser how to process and 
control what is seen on a screen and/or is heard on speakers coimected to the 
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compuler running Ihe browser when llie document is processed. HTML 
docunicnis may be transmiUcd over a nclwork through the I lypcrlexl Transfer 
Protocol ("inTP"). The term "Hypertext" is a reference to tlie ability to 
eml^ed links into the text of a document that allow comnnniicalion to other 

5 documents whicii can be accessed in the network. 

Thus liiere exists a need for an aulomated banking machine and system 
that can be used in a wide area network such as the hiternet while providing a 
high level of security. There further exists a need for an automated banking 
machine and system which provides a user with the familiar interface and 

10 transaction options of their home institution when operating foreign institution 
machines. There further exists a need for a machine which may provide more 
transaction options and types of promotional and printed materials to users. 

DISCLOSURE OF INVENTION 

It is an object of the present invention to provide an automated banking 
1 5 machine at which a user may conduct transactions. 

It is a further object of the present invention to provide an automated 
banking machine that may be operated through connection to a wide area 
network. 

It is a further object of the present invention to provide an automated 
20 banking machine and system that provides a user with a familiar interface and 
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Iransaclion options oflhcir home insliliilion at machines operated l^y foreign 
institutions. 

It is a further object of the present invention to provide an automated 
banking machine that communicates using HTML dociuuents and TCP/IP 
5 messages. 

It is a further ol^jecl of the present invention to provide an automated 
banking machine that enables the connection of the banking machine to a 
user's home institution through HTML documents and TCP/IP messages 
generated responsive to indicia on a card input by a user. 
10 It is a further object of the present invention to provide an automated 

banking machine and system that accomplishes transactions over a wide area 
network while maintaining a high level of security. 

It is a further object of the present invention to provide an automated 
banking machine and system that controls connection of the banking machine 
1 S to foreign addresses through a proxy server. 

It is a further object of the present invention to provide an automated 
banking machine that limits the operation of devices in the machine through a 
local device server. 

It is a further object of the present invention to provide an automated 
20 banking machine and system that is operable through connection to the 
Intemet. 
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11 is a fiirllier objccl of the preseiU inveiilion lo provide an aulomaleil 
banking machine thai may be used lo provide a user wilh more lypes of 
messages inchiding messages targeted to particular users. 

It is a further object of the present invention lo provide an automated 
banking machine which is capable of providing users wilh a wider variely of 

primed documents. 

It is a further objecl of the present invention lo provide an automated 
banking machine which provides addilional options for identifying authorized 
users. 

It is a further object of the present invention to provide an automated 
banking machine that can be used in connection with existing transaction 
systems while providing enhanced fiinctionality. 

It is a further object of the present invention to provide an automated 
banking machine which provides enhanced diagnostic and service capabilities. 

It is a further object of the present invention to provide an automated 
banking machine which performs transactions at a rapid pace. 

It is a further object of the present invention to provide improved 
systems in which automated banking machines are used. 

It is a further object of the present invention to provide improved 
methods of operation for automated banking machines and systems. 

Further objects of the present invention will be made apparent in the 
following Best Modes for Carrying Out Invention and the appended Claims. 
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The foregoing objccls are accomplished in a prefcncd enibodimcnl of 
Ihc invention by an aiilomaled banking machine lhal includes an oulpiil device 
such as a display screen, and an input device such as a touch screen or a 
keyboard. The banking machine further includes devices such as a dispenser 

5 mechanism for sheets of currency, a printer mechanism, a card reader/writer, a 
depository mechanism and other physical transaction function devices that are 
used by the machine to accomplish banking transactions. 

The banking machine further includes a computer. The computer is in 
operative connection with the output devices and the input devices, as well as 

1 0 with the sheet dispenser mechanism, card reader and other physical transaction 
function devices in the banking machine. The computer includes software 
programs that are executable therein. The software programs include an 
HTML document handling portion. The HTML document handling portion 
operates to send and receive HTML documents and HTTP messages. The 

1 5 HTML document handling portion is preferably in connection with the output 
device to display screens including hypertext link indicators. The HTML 
document handling portion is also preferably in connection with the input 
device which enables user selection and the generation of response messages 
from the computer. The HTML document handling portion preferably 

20 operates in connection with a JAVA software environment and has the 

capability of executing instructions in JAVA script transmitted with HTML 
documents. 
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The soQwarc in Ihe coiiipiiler furlher preferably includes a device 
applicalion porllon. The device application porlion includes software thai is 
operative to control the sheet dispenser and other devices. In the preferred 
fomi of the invention the device application portion includes a plurality of 
JAVA applets for operating the devices in the machine. 

The computer in the automated banking machine further includes a 
device interfacing software portion. The device interfacing software portion 
operates to receive messages from the device application portion and to cause 
the devices to operate through appropriate hardware interfaces. In one 
preferred form of the automated banking machine, the HTML document 
handling portion, device application portion and device interfacing software 
portion each reside on the same computer and communicate at different IP 
ports. 

The automated banking machine of the invention in one configuration 
communicates using TCP/IP messages in an intranet which includes a 
plurality of such machines. The intranet is in turn connected to at least one 
computer which is operated by a home institution. The home institution is the 
entity that operates the banking machines. 

The computer of the home institution preferably includes a home 
HTTP server, a proxy server and a device server. The proxy server 
communicates through the intranet with the HTML document handling portion 
of the software in each of the banking machines. The proxy server is also 
connectable to a wide area network, such as the Internet, to which foreign 



CA 02271213 1999-05-07 
10 

servers are conneclcd. The device server is operative lo pass messages 
between the device application portion and tiic device interfacing software 
portion of the lianking machines. The device server may inchide monitor 
soflware which monitors and selectively limits the use and operation of the 

5 devices in tlic banking machine. This provides a level of security. 

The automated banking machine and system is operative to phice a 
user in connection with the institution where they have their accounts. This 
can be either the home institution that operates the banking machine where the 
user is present, or a foreign institution which is connected to the wide area 

1 0 network. To operate the banking machine a user provides inputs which 

correspond to an address, such as a URL address, through an address input 
device. The HTML document handling portion operates to connect the 
banking machine to the server corresponding to that address. This is 
preferably accomplished by the user having indicia representative of the 

1 S address on a card that is read by a card reader in the banking machine, or other 
input device which identifies the user or an institution or entity with which the 
user has accounts. 

The HTML document handling portion is responsive to the address on 
the card or other input data to connect through the proxy server to the user's 

20 institution. If the user's home institution address corresponds to the home 

server, the banking machine operates responsive to messages from the home 
server. If however the user's input address corresponds to an address of a 
foreign server, the proxy server is operative to communicate through the wide 
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area network with the foreign server al the customer's home institution. If the 
customer causes the machine to connect a server operated by a foreign 
institution, tlic HTML documents sent from the foreign institution coirespond 
to those normally provided l>y the foreign institution. As a rcsuh the customer 

5 is familiar with the interface produced by these documents and will be able to 
more readily operate the banking machine. 

The foreign server or home server operate the banking machine by 
sending HTML documents that include instructions for operating the devices 
in the banking machine. The instructions are transmitted from the HTML 

1 0 document handling portion to the device application portion of the software, 
which operates the devices in response to the instructions. The instructions 
from the device application portion to the devices in the automated banking 
machine are passed through the device server of the home institution. This 
helps to maintain security. In addition, the proxy server includes screening 

1 5 software which limits the foreign servers which may connect to and operate 
the banking machine. This is referred to as a "fire wall." 

Embodiments of the present invention also provide enhanced user 
interfaces and for the printing of a wide variety of documents with the banking 
machine. The invention also enables achieving enhanced functionality while 

20 utilizing existing transaction networks and automated transaction machines. 



BRIEF DESCRIPTION OF DRAWINGS 
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Figure 1 is a schematic view of a network condguration incliiding the 
aiitomatcil banking nuichinc apparatus and system oTthc present invention. 

Figure 2 is a schematic view ofa preferred embodiment ofan 
automated banking machine of the present invention. 

Figures 3 tlirough 24 show schematic views of the automated banking 
machine, an intranet connecting the banking machine to a computer system of 
a home bank and a wide area network connecting the computer system of the 
home bank to a foreign bank. 

Figures 3 through 18 schematically represent steps in a transaction 
carried out at the banking machine with the computer system of the home 
bank. 

Figures 19 through 24 schematically represent steps in a transaction 
carried out at the banking machine with the computer system of the foreign 
bank. 

Figure 25 is a schematic view of a network configuration including an 
alternative embodiment of the automated banking machine of the present 
invention. 

Figure 26 is a schematic view of frames in the HTML document 
handling portion of the alternative embodiment of the automated banking 
machine shown in Figure 25. 

Figure 27 is a schematic view of a customer interface of an automated 
banking machine and the function keys and keypad keys included in the 
interface. 
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Figures 28-30 schematically represent exemplary steps in converting 
function key and keypad key inputs to keyboard stream and mouse stream 
inputs. 

Figure 31 schematically represents exemplary steps in printing 
documents with the automated banking machine. 

BEST MODES FOR CARRYING OUT INVENTION 

Referring now to the drawings and particularly to Figure 1, there is 
shown therein a network configuration schematically indicated 10, which 
includes the automated banking machine apparatus and system of one 
preferred embodiment of the present invention. Network 10 includes a 
plurality of automated banking machines 12 which in the preferred 
embodiment of the invention are ATMs. ATMs 12 are connected to a 
computer system of a home bank schematically indicated 14. Home bank 
computer system 14 is the computer system that is operated by the bank or 
other institution which has primary responsibility for the ATMs 12. Home 
bank computer system 14 is connected to the ATMs 12 through an intranet 16. 
Intranet 16 is preferably a local or proprietary network that provides 
communication between the computer system 14 and the banking machines 12 
using messages in the transmission control protocol/internet protocol 
("TCP/IP") format. 
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The messages lhal are communicated Ihroiigh the intranet 16 are 
preferably TCP/IP messages and liyperlexl mark up language ("HTML") 
documents. In one preferred embodiment of the invention the HTML 
documents sent through intranet 16 include embedded olycct oriented 

5 programming instructions, preferably in the JAVA® format which has been 
developed by Sim Microsystems. The messages sent through intranet 16 may 
be sent in an encrypted or unencrypted form depending on the nature of the 
system and the security needs of the home bank. 

It should be understood that embodiments of the invention may 

1 0 process other foniis of documents which include tags or instructions therein. 
For example a form of '^extended" HTML has recently been proposed which 
may be used in embodiments of the invention. For purposes of the invention 
all such forms of languages and variants which include documents, which 
documents include instructions therein shall be referred to as HTML 

1 5 documents. Likewise, while JAVA® is used in the described embodiment, 
other programming languages may be used. For example, Active-X™ 
developed by Microsoft Corporation or other languages may be used in other 
embodiments. Further it should be understood that the instructions included in 
documents may be operative to cause a computer to access other documents, 

20 records or files at other addresses to obtain a program to carry out an 
operation. 

Home bank computer system 14 is also connectable as shown to a wide 
area network 18. In some embodiments of the invention the wide area 
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nelwork 1 8 is the Internet. In other embodimenis of the invention, other wide 
urea networks may be used. The wide area nelwork preferably coniniunicales 
nicssajjcs in TCP/IP between numerous computer systems connected to the 
wide area nelwork. These foreign computer systems are scliemalically 
5 represented by servcre 20, 22, 24, 26 and 28. It should be undei"stood that 
servers 20 tiirough 28 may be operated by or connected to olher fniancial 
institutions throughout the world. Servers 20 through 28 preferably operate by 
communicating HTML documents and olher HTTP messages. 

Figure 2 shows a schematic view of Ihe ATM 12 used in conneclion 

1 0 with one preferred embodiment of the invention. ATM 1 2 includes a touch 
screen 30. Touch screen 30 includes a display screen which serves as an 
output device for communication with a user of the machine. Touch screen 
30, because it is a touch screen, also serves as an input device for receiving 
input instructions from a user. Touch screen 30 is connected through an 

15 interface 32 to a computer 34 which is preferably housed within the machine. 
Alternative embodiments of the invention may include other output devices 
such as audio speakers. 

Computer 34 is also in connection with a plurality of transaction 
function devices 36 which are included in ATM 12, Devices 36 include for 

20 example, a card reader/writer mechanism 38 and a keyboard 40. Devices 36 
further include a sheet dispenser mechanism 42 which is operative to dispense 
sheets, which in some preferred forms of the invention are currency or bank 
notes. Devices 36 also include a depository 44 for accepting deposits into a 
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secure localion in Ihe machine. A receipt printer 46 for providing transaction 
receipts to customers is also inchiilcd among devices 36. A journal printer 48 
is also inchiiletl among the devices for keeping a hard copy record of 
transaction information, hi other embodiments other or additional transaction 

5 function devices which can-y out other transaction functions may be used. 

Other embodiments may include fewer transaction function devices. It should 
be further understood that while the described embodiment of the invention is 
an automated banking machine, the principles of the invention may be 
employed in many types of transaction machines that do not necessarily carry 

1 0 out banking transactions. 

Each of the devices is operatively connected to an internal control bus 
50 within the banking machine 12. The control bus 50 outputs the internal 
messages to the particular devices. Each device has an appropriate hardware 
interface which enables the particular device to operate to carry out its 

1 5 respective function in response to the messages transmitted to it on control bus 

50. Card reader/writer 38 has a hardware interface schematically shown as 52. 
Hardware interfaces 54. 56, 58, 60 and 62 are respectively operative to 
connect keyboard 40, sheet dispenser mechanism 42, depository mechanism 
44, receipt printer mechanism 46 and journal printer mechanism 48 to the 

20 control bus 50. 

Computer 34 has several software programs that are executable 
therein. In the preferred embodiment of the invention these software programs 
include a device interfacing software portion generally indicated 64. Device 
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interfacing software portion 64 preferably includes a software device interface. 
66 that communicates electronic messages with the control bus 50. The 
device interface software portion 64 also preferably includes a device manager 
68. The device manager is preferably operative to manage the various devices 

5 36 and to control their various states so as to be assured that they properly 

operate in sequence. The device manager is also preferably operable to create 
device objects in the software so as to enable operation of the devices by at 
least one object oriented program 70. Device interfacing software portion 64 
also includes the object oriented program portion 70, which in one preferred 

10 embodiment is an application written in the JAVA language. Program 70 
works in conjunction with the device manager to receive object oriented 
JAVA messages which cause the devices to operate, and to transmit device 
operation messages indicative of a manner in which devices are operating 
and/or are receiving input data. 

15 The device interfacing software portion 64 in the described 

embodiment operates on computer 34 and communicates through a physical 
TCP/IP connection 72 with the intranet 16. The physical connection may be 
analog dial-up, serial port, ISDN connection or other suitable connection. In 
the configuration of the system as shown, device interfacing software portion 

20 64 communicates at the IP address of computer 34 and at an IP port or socket 
indicated 74 that is different fi-om the other software applications. In other 
embodiments of the invention, device interfacing software portion 64 may 
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operate in a different computer than the other software applications of the 
invention. 

It should further be understood that although in the preferred 
embodiment of the invention the device interfacing portion 64 is software, in 
other embodiments of the invention all or portions of the instruction steps 
executed by software portion 64 may be resident in firmware or in other 
program media in connection with one or more computers, which are 
operative to communicate with devices 36. For purposes of the invention all 
such forms of executable instructions shall be referred to as software. 

Other software also operates in computer 34. This software includes 
HTML document handling software which includes a browser, schematically 
indicated 76. In the preferred embodiment of the invention the HTML 
document handling software includes a browser provided by Netscape®. 
However in other embodiments other HTML document handling and 
communicating software and browser software, such as Hot JAVA® by Sun 
Microsystems or Internet Explorer™ from Microsoft, may be used. Browser 
76 communicates in computer 34 at an IP port indicated by 78. 

Browser 76 is in operative connection with JAVA environment 
software 80 which enables computer 34 to run JAVA language programs. 
JAVA language programs have the advantage that they operate the same on a 
variety of hardware platforms without modification. This "write once\run 
anywhere" capability makes the JAVA environment well-suited for the 
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described embodiment of the invention. However other embodiments may use 
different types of software programs. 

The JAVA environment software 80 enables computer 34 to execute 
instructions in JAVA script, schematically indicated 82. The instructions that 
are executed by the computer in JAVA script are preferably embedded JAVA 
script commands that are included in the HTML documents which are 
received through the browser 76, The browser 76 in connection with the 
JAVA environment software 80 which executes instructions in the embedded 
JAVA script 82, serve as an HTML document handling software portion for 
transmitting and receiving HTML documents and TCP/IP messages through 
the IP port indicated by 78. 

Computer 34 also has executable software therein having a device 
application portion 84. The device application portion 84 contains executable 
instructions related to operation of the devices 36. In the preferred 
embodiment of the invention, Ihe device application portion consists of a 
plurality of JAVA applets. In the described embodiment the applets are also 
preferably programs operable to control and keep track of the status of the 
devices with which they are associated. Certain applets are also preferably 
operable to configure the browser to communicate messages. Certain applets 
manage security and authenticate entities that use the ATM. 

In the described form of the invention, JAVA applets are associated 
with ftmctions such as enabling the card reader mechanism, notifying the 
browser when a user's card data has been entered, operating the receipt printer 
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mechanism, operating the journal printer mechanism, enabling the customer 
keyboard and receiving data input through the keyboard, operating the sheet 
dispenser mechanism, operating the depository, navigating to document 
addresses, timing device functions, verilying digital signatures, handling 
5 encryption of messages, controlling the mix of bills dispensed from multiple 
sheet dispenser mechanisms, calculating foreign exchange, and ending a 
transaction and instructing the browser to return to communication with the 
home server. Of course, in other embodiments, other applets may be used to 
control devices and use data to carry out various desired flinctions with the 

1 0 machine. The device application portion 84 communicates in the computer 34 
at an IP port indicated 86. 

In the described embodiment of the invention, the device application 
portion 84 of the software does not communicate its messages directly to the 
device interfacing software portion 64. As later explained, this provides 

1 5 heightened security. However it should be understood that embodiments of 
the invention may provide for the device application portion 84 to directly 
communicate device operation messages to the device program 70. This may 
be done either internally using TCP/IP, by delivery of messages in a 
conventional manner through a queue established in the operating system of 

20 the computer that is associated with the software that interfaces with the 
devices, or by direct call to this software. 

From the foregoing discussion it will also be appreciated that certain 
applets in the device application portion 84 may correspond to devices which 
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are not present in all automated teller machines. For example an automated 
teller machine that operates only as a cash dispenser does not include a 
depository mechanism like depository 44. To accommodate the situation 
where a user requests a transaction that is not physically possible with the 
ATM 12, the device interfacing software portion 64 may be programmed to 
provide an appropriate response message to indicate that the function is not 
available. 

Alternatively, the device interfacing software portion may include a 
function which checks for the presence or absence of each type of physical 
device within the ATM. Infonnation indicative of the devices present in the 
ATM may be included as part of the messages generated by the ATM. For 
example, information indicative of the devices which are operative in the 
ATM may be included as a portion or several parts of the URL addresses to 
which messages are directed by the ATM. In this way, the URL in the server 
to which the ATM connects may be configured for providing only HTML 
documents which correspond to the types of transactions that the ATM is 
capable of performing. As a result the browser avoids displaying documents 
which include references to transaction types that the machine is not capable 
of performing. Thus for example, a machine may avoid producing a display in 
response to a document which includes a reference to a deposit transaction if 
the machine does not include a depository. 

Alternatively the machine may include in memory, data representative 
of the ftinctional devices included in the machine. This may include for 
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example diUu rcprcscntalivc ofa phiralily ordcviccs in the machine and the 
condgiiraHons ofsuch devices, or allernalively, a designator such as a machine 
number sudlcienl to idenlify \\\c capabilities oflhe machine. The device data 
indicative of the rimctional devices in the machine is communicated to a 
5 server and tlie server is operative lo deliver the appropriate HTML documents 
for the devices present in the machine. This may be done based on the data 
corresponding lo the device data from the machine or may be resolved Trom a 
memory which holds data representative of the functional devices in a 
machine associated with a particular designator. Documents selectively 

1 0 delivered by ihe server to the browser of the machine will include the 

appropriate references to the functional devices present in the machine. These 
documents may be static documents or may be generated at run time from sub- 
documents or otherwise, to provide the appropriate outputs and instructions to 
the output devices of the transaction machine. 

15 Figure 3 shows the ATM 12 in communication through the intranet 16 

with the home bank computer system 14, Computer system 14 includes a 
proxy server 88. System 14 further includes a home HTTP server 90. 
Computer system 1 4 further includes a device server 92. The proxy server, 
home HTTP server and device server may be included in a single computer as 

20 shown, or in other embodiments may be separate computers. Additional 
servers may be operative in other embodiments. 

The home HTTP server 90 is preferably in communication with a data 
store and is in electronic communication with a back office computer system. 
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sclicmalically indicaled 94. Back olTice compiilcr system 94 is opcralivc lo 
keep track olMobiting or crciliting customers* accounls when they coiuliiet 
Iransactions at tl)e aiilomuleii hanking machines, hi addition hack onicc 94 is 
also preferably operative to track transactions for pitqioscs of accomplishing 
5 settlements with other institutions who are participants in the system and 
whose customers conduct transactions at the ATMs 12. 

As later explained, proxy server 88 is also operative in the descril>ed 
embodiment to communicate through the wide area network 18 with foreign 
servers such as foreign server 96. Foreign server 96 is an example of a server 

] 0 operated by an institution or entity other than the institution which operates 
computer system 14. It should be understood that while foreign server 96 is 
indicated as operated by a "foreign" institution, this is not necessarily 
indicative that the institution is located in another country from the institution 
that operates computer system 14. However, it is possible that foreign server 

IS 96 could be located in such a foreign country, including a country in which the 

language spoken is different from that generally used in the country where 
ATM 12 is located. 

The conduct of transactions using the ATM 12 is now explained with 
reference to Figures 3-24. It should be understood that the following 

20 described transaction flows are merely examples of the operation of the 

apparatus and system, and the apparatus and system may be configured and 
operated in numerous ways to carry out transactions. 
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At the start or an exemplary transaction, as schematically represented 
in Fiijurc 3, the browser 76 communicates through the intranet 16 with the 
proxy sci-ver 88. The communication is established preferably in a manner so 
that HTML documents intended to attract customers to the ATM 12 arc 

5 displayed on the touch screen 30. This is rcfeiTcd to as the "utlrael mode," 
These HTML documents which are processed in the browser to produce the 
outputs in the form of screens on the touch screen 30 (and/or outputs through 
other output devices included in the machine) may originate from home HTTP 
server 90 which is operative to deliver the HTML documents to the proxy 

1 0 server. The home HTTP server sends the messages addressed to the IP port 
associated with browser 76, so as to cause their display at the proper ATM 
machine. It should be understood that while in this example, home server 90 
is described as communicating with the ATMs through the proxy server 88, 
the server 90 may in other systems encompassed by the invention 

1 5 communicate directly with the ATMs. 

A fundamental advantage of the system is that home HTTP server 90 
may deliver documents selectively to the ATMs 12 connected to the intranet 
16. These documents may include messages or material tailored to the 
particular location in which an ATM 12 is located. Examples of particularly 

20 tailored screens may include bilingual messages in certain neighborhoods or 
information concerning currency exchange at various ports of entry. The 
material or messages could include advertising for various products or services 
or other material targeted to particular machine locations. The JAVA applets 
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ami JAVA scripl are loaded from a central location providing scleclive 
soHwarc dislribulion in Ihc ATMs which may also be used lo lailor Ihc ATM 
lo its environment by causing it lo access documents which include material 
intended to be useful in that location, and which is not provided in documents 
delivered to at least some other machines in the system. 

Systems of the present invention may be configurctl to have selected 
machines access HTML documents at different addresses, so that the 
particular documents accessed include the material targeted to users of the 
particular machine. Alternatively, a machine may communicate machine data 
indicative of its identity and/or location to a server. From the machine data, 
and data stored in a data store in connection with the server, the server 
operates to deliver the documents including the targeted material. This may 
be accomplished by assembling subdocuments, or otherwise, to generate the 
documents that will be delivered to the browser of the particular machine. In 
addition it should be understood that while in the embodiment shown the 
HTML documents are accessed through a server of an institution associated 
with the machine, the documents used for the attract mode may be accessed 
from other servers operated by other entities. 

The touch screen 30 in this exemplary transaction sequence displays a 
screen which includes an icon which indicates in one or more languages that to 
commence a transaction a user should touch the screen. If a user touches the 
screen in the area of the icon an input signal is generated. The input signal or 
HTTP message is transmitted through the browser 76 to the home address of 
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Ihe home HTTP server 90 to which Ihe ATM 12 is currently in 
conimuniciilion. The nicssuBC gcncralcd back to the home I ITTI^ server is 
represented by the arrows directed from the browser 76 to the intranet 16, 
from the intranet 16 to the proxy sci*vcr 88, and Trom the proxy server to tiie 
HTTP server 90 in Figure 3. 

In response to the home HTTP server 90 receiving the message 
indicating that a customer has touched the icon on the screen, the liome server 
is operative responsive to the address accessed to send a message through the 
proxy server 88 (or in other embodiments directly) to the browser 76. This 
message preferably includes an HTML document which when processed 
through the browser produces a screen instructing the customer to insert their 
card into the card reader mechanism 38. The HTML document flow which is 
represented graphically in Figure 4, preferably also includes embedded JAVA 
script or other instructions which operate in the JAVA environment to 
communicate a message to the JAVA applet responsible for enabling the card 
reader in the device application portion 84. In one preferred embodiment the 
instructions provide a pointer or tag to the applet which executes responsive to 
receipt of the document instructions. Of course in other embodiments other 
software and approaches may be used. 

As shown in Figure 5, in response to the embedded JAVA script 
activating the JAVA applet associated with the enable card reader function, 
the JAVA applet in the device application portion 84 communicates with the 
device server 92. The device server 92 includes a device server program 98 
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which in the preferred embodiment is a JAVA program that enables 
communicalion with the JAVA applets and the device server application 100. 
The device server 92 further preferably includes a monitor soHware 
application 1 02 which is operative to monitor device operation instructions. 
S The monitor soQware minimizes the risk of fraud or abuse in a manner later 
explained. 

Returning to the sample transaction, in response to receiving the enable 
card reader message from the device application portion 84, the device server 
92 is operative to generate a message through the intranet 1 6 to the device 

1 0 interfacing software portion 64 of the ATM 1 2. This message which 

comprises an HTTP record including instructions for operating the card reader, 
is directed to the IP port indicated 74 which is where the device interfacing 
software portion 64 communicates. In response to receiving this message, the 
software portion 64 is operative to send a message or messages on the control 

1 5 bus 50 which enables card reader mechanism 34. 

Continuing with the transaction as shown in Figure 6, the input of the 
card by the customer to the card reader 34 is operative to cause the card data to 
be read and the device interfacing program portion 64 to send a message to the 
device server 92 indicating the card data has been read. This message is 

20 transmitted by the device server through the intranet 1 6 to the device 

application portion 84. The device application portion then sends a message 
to the device server requesting the card data. The device server 92 transmits a 
message with instructions to deliver the card data from the device interfacing 
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sonware portion 64 which responds with a message sending Uie card data 
through the inlranet {o Ihe device server. The device sei-ver, if there is no basis 
for slopping Ihe (ransaclion, transmits an iriTI* record inchiding card data 
back through the intranet 16 to the device application portion 84. 

5 hi one preferred embodiment of the invention, the card input by a user 

or customer inchides indicia which corresponds to an address associated with 
llie user in the network, hi such an embodiment tlie indicia corresponds to a 
uniform resource locator ("URL") address which provides infomialion on the 
computer where the user information resides, as well as a directory or 

1 0 subdirectory which includes the user information and the name of the 

document or resource that includes the user information. The URL address 
may be encoded on a customer's card. The address may be encoded on track 3 
of a magnetic stripe, in other locations within the magnetic stripe data or 
through encoding other readable indicia on the card. Alternatively, if the 

15 customer's card is a "smart" card which includes semiconductor storage 

thereon, the URL address associated with the customer may be included as 
part of the stored data on the integrated circuit chip on the customer's card. 
Alternatively, a URL could be derived from other data on the card by 
accessing a data base in which address data is correlated with other data read 

20 from the card. The data necessary to derive the address for accessing 

documents associated with a customer could also be derived from inputs to 
input devices other than or in addition to card data, including for example 
biometric data which is input by a customer through a biometric reading 
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device. Sueh biomclric data may include for example, data corresponding lo 
one or more fingciprints, ilala from Ihc user's appearance or combinalions 
Ihercof. 

For example and wilhoul limitalion, data input by a customer such as 
llirough a card input lo a card reader may correspond lo an address Tor 
accessing an I TH P record, which may be a fde or documenl which includes 
infomiation which can be used for verifying the identity of a user. This record 
could include data corresponding lo a PIN number. The infonnalion niay 
inckide bionielric data corresponding to the authorized user of the card. The 
browser may access the record and use Ihe contents ofthe record such as data 
and/or instructions to verify that the indicia corresponding to biometric data in 
the record corresponds to the biometric data of the user entering the card. 
Alternatively, input data representative of appearance, voice, other features (or 
combinations thereoO or other input data, may be used to generate one or 
more addresses which correspond to a user, and the content ofthe record at the 
accessed address used to verify that the user at the machine corresponds to the 
user associated with the record. Numerous approaches within the scope ofthe 
invention may be used. The information in the record corresponding to a user 
may likewise be used to authorize certain functional devices on the machine to 
operate for the user while other devices may not. For example, a user who is 
overdrawn may have information in the record accessed that prevents them 
from actuating the cash dispenser, while users who are not overdrawn may 
include information which enables such operation. Alternatively, the absence 
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of informalion in a corresponding record may enable operation, while the 
incUision of information selectively limits the operation of devices. 

Returning to the exemplary transaction, the dehvery of the card data 
from a successfully read card is delivered responsive lo the programming of 
the device application portion 84 to a JAVA applet associated with notifying 
that the card data has been entered. In response, the JAVA applet operates to 
generate JAVA script which configures the browser with the URL address 
corresponding to the data read from the card. The JAVA applet is also 
preferably operative lo open a record schematically indicated 104 concerning 
the transaction, which includes the user's URL address, the time and other card 
data. This record in a preferred embodiment may be stored in memory as data 
in an object in software. The object is preferably used to accumulate data as 
the transaction proceeds. The data stored in the transaction data object 
preferably includes data input through input devices by the user as well as data 
representative of operations carried out by transaction function devices. 

The record or transaction data object provides persistence through what 
may be several different transaction steps executed by the customer. The 
ability to use and share the data in a number of different operations avoids the 
need to derive it or obtain it from a customer more than once in the course of a 
user session involving a number of transaction steps. The use of a transaction 
data object enables applets to run largely independently, obtaining needed data 
from the transaction object. The approach also enables the record or data 
object to be used to produce an appropriate record at the end of the transaction 
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session. This record may be slored, collected inlo a batch or delivered to 
selected addresses in a local or wide area network. 

As schematically shown in Figure 7, in response to the browser 76 
receiving the URL address data, the browser is operative lo transmit a message 
through the intranet 16 to the proxy server 88. For puqioses of this example, 
the URL address associated with the card data is that ofa customer associated 
with the home bank which operates system 14. As a result, the customer's 
URL address will cause the message to be directed from the proxy server 88 to 
the home HTTP server 90 and to access the corresponding document at the 
address therein. Alternatively, in other systems the connection may be made 
directly with server 90 without the intervening proxy server 88. As previously 
discussed, the URL address may also include data representative of the 
devices which are operative in the ATM. 

In response to receiving the message, home HTTP server 90 finds the 
data corresponding to the customer's URL address data in its associated 
memory and delivers to the browser at its IP port with an HTML document. 
This HTML document may include a screen acknowledging the particular 
customer by name as well as with the name of the banking institution or other 
entity which operates the home bank computer system 14. 

In addition, the HTML document preferably includes embedded JAVA 
script which has a digital signature or a means to obtain a digital signature 
associated with the home HTTP server 90. The script instruction included in 
the document in certain embodiments causes the device application portion to 



CA 02271213 1999-05-07 



32 

access I rrrP iuUlrcss on a server, which in Ihe ilescriheil cinboiliiuenl is 
server '^0. Tlie I \T\V aildress conespomis lo an I I TPP record wluch incliiiles 
al least one instnielion anil preferably incliiiles a program such as a JAVA 
applel or Active-X file. The instnielion is used lo operate the appropriate 
transaction function device. The I \TTP record preferably includes data 
representative of a siBnalure, such as a digital signature. This digital signature 
is received responsive to the JAVA script 82 and processed in the device 
application portion 84. A JAVA applet processes the digital signature to 
authenticate it and if it is an acceptable signature authorizes operation of the 
banking machine. In certain cmliodiments the applet may compare the 
signature to signature data stored in memory for a predetermined relationship, 
such as a match. 

After the applet verifies that HTTP server 90 or other accessed HTTP 
record has sent a proper digital signature, the transaction will be allowed to 
continue. If for some reason a proper digital signature has not been sent, the 
JAVA applet will stop the transaction and return banking machine 12 back to 
the condition prior to the start of the transaction by connecting the ATM to the 
address associated with the attract mode in home server 90. The use of signed 
instructions may be used to assure that the various transaction function devices 
are only operated in response to appropriate messages. The use of signed 
instructions may be particularly appropriate for instructions that run the sheet 
dispenser or otherwise provide value to the user of the machine. 
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In \Uc example il will be iissiiiued thai ihe digilal signaliirc received is 
a proper sigiuUiire, in wliicl) case a message ts reUirued Ironi Ihe browser 76 In 
home server 90 indicating thai Ihe transaction may proceed. As sliown in 
iMgiirc 8, in this exemplaiy transaction Ihe IITI P home server 90 then 
operates to senil an H TML ilocumenl to Ihe browser 76 which includes 
instructions which wlicn processed produce a page or screen wliich instructs 
Ihe customer to cnler their personal idcntiTication number or PIN. This 1 ITML 
document preferably includes embedded JAVA instructions which operate lo 
cause the device application portion 84 enable the keyboard 40 of the ATM so 
the machine may receive Ihe PIN number. Such a message is schematically 
shown in Figure 8 with the JAVA script 82 signaling the JAVA applet 
responsible for the keyboard that it has been requested to enable the keyboard. 
In response the JAVA applet in the device application portion 84 sends a 
message through the intranet 16 to the device server 92. The device server 92 
sends a message back through the intranet to the device interfacing software 
portion 64 in the ATM. The instructions in this message causes the device 
software to enable keyboard 40. The JAVA applet responsible for enabling 
the keyboard is also preferably operative to update the transaction record 104 
to indicate that the PIN was requested. 

As shown in Figure 9, the PIN entered through the keyboard 40 is 
transmitted in a message from the device interfacing software portion 64 to the 
device server 92. The device server 92 returns a message to the responsible 
JAVA applet in the device application portion. The JAVA applet then 
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opcaUcs to sciul i» mcssiiijc b;ick (luougli llic I I TMI. tlociimcnl hHndlinj- 
poi1i<»n ami llio browser 76 lo l\w I ITI'P mWrcss ollwxuc server 90, Phis 
message includes ilala represenlatlve olMlie IMN inpiil by the cusiomer. In 
some emboilimeals il is nol ilcsirable lo display llie ciislomcr's IMN on ihe 
screen. In siicli cinbodimcnls Ibe keyboard applet may be operative to display 
a deliuiit cbaracler on the screen such as a "*" symbol or other symbol in lieu 
ofthe PIN digits. Furlber as later discussed it may be desirable to avoid 
transmission of PIN or other data through the brow^scr, in which case PIN data 
may be handled as a separate HTTP message or in other manner to reduce the 
risk of disclosure. 

The software operating in connection with HTTP server 90 is then 
operative to either verify the PIN itself or to verify the customer's PIN number 
and account number by sending it to the back office 94 and waiting for a 
response. Altematively, customer PIN verification may be carried out in the 
ATM through an appropriate applet. This can be done in situations where data 
on a customer's card, such as an account number, can be correlated to the 
customer's PIN number through an algorithm. The embedded JAVA script in 
the HTML messages may include or point to an address to obtain the data 
and/or instructions which the applet uses to perform this verification function, 
including certain encryption key data. This may include user information in 
the HTML document or other record data that was accessed in response to the 
user's card data. As shown schematically in Figure 9, the transaction data 
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object 104 is also appropriately updated by the applet to indicate the entry of 
the customer's PIN. 

In alternative embodiments the machine may include a biometric 
reader device or other input device to accept data from a user. The user may 
input data through such a device which may be used in lieu of, or in addition 
to, PIN data to verify that the user is an authorized user. This may be done for 
example by comparing the user data input to information corresponding to the 
authorized user of the card included in a record or a document which has an 
HTTP address and is accessed by a browser or by an HTTP client application 
through an HTTP server in response to card data. Alternatively input data 
may be used to generate addresses for documents or records which are 
accessed by the browser or client, and which records or documents contain 
information that is used to verify the user's identity. For example, data 
concerning users may be stored in a data store in connection with an HTTP 
server, which delivers data from a record responsive to the user data, which is 
used to verify the user's identity. 

It should be noted that the page or screen which requests the customer 
to enter their PIN is shown generated from the home HTTP server 90. This is 
preferably a screen that is associated with the particular customer's URL 
address. This will be the interface of the customer's home bank and will be 
familiar to the customer. Alternatively, the customer address may access what 
may be essentially the customer's personal "home page" with the institution 
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that operates computer system 14, As such, it is not only something the user is 
familiar with, but is ideally tailored to the user's particular transaction needs. 

Alternatively, the document(s) or record(s) which contain the customer 
data may be used to generate the addresses for other documents. The 
S information may also be used to generate a document for the particular 

customer in the particular circumstances. This approach may be useful to 
reduce the effort associated with developing in advance a personal visual page 
or document for each customer. 

Approaches for accomplishing this may involve including various 

10 types or categories of user infonnation in the document(s) or record(s) that 

pertain to a particular customer This may include information such as gender, 
related persons, account types, permitted transactions, customer preferences, 
customer interests, account balances, previous offers declined or accepted and 
other information. This customer information can be used by an appropriate 

1 S applet among applets 86 to address and/or develop an appropriate document 

for the browser to access based on the customer "profile". In addition, the 
profile applet may take into consideration the transaction devices present in 
the particular machine, information on which is stored in a data store in the 
machine or elsewhere in the system, as well as other factors such as the day of 

20 the week and time of day based on a system clock. In this way the machine 
determines the appropriate document to access or generate for the particular 
customer under the particular circumstances. 
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The logic used in the profile applet may act to cause documents to be 
built or accessed for the customer which includes transaction options based on 
the customer information, information about the terminal and other factors. 
The profile applet may operate to offer transaction options or information 
5 selectively based on the customer information. For example, the operator of 
the machine may offer incentives, premiums, additional transaction options or 
advertising information selectively to customers. Certain types of customers 
of the institution operating the machine may receive screen outputs with 
options that encourage them to do more business or different types of business 
10 with the institution. Likewise, customers that are identified as customers of 
foreign institutions may be provided with incentives to do business with the 
institution operating the machine. 

The profile applet may operate to cause the computer to access other 
documents in other servers, such as stock market data, and selectively provide 
15 it to customers. It should be understood that the profile applet may operate to 
determine an address or generate documents to produce initial display screens 
of a transaction sequence. The profile applet may also operate to provide 
information or access or produce documents to generate visual outputs to the 
customer at other points in a transaction or between transactions. This may 
20 fijrther be used in systems in which the operator of the machine is able to sell 
paid advertising to third parties and then access the HTTP records such as 
HTML files for those third parties' products or services. Such accessing may 
be done based on a periodic or other basis, but may be done effectively by 
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selecting the HTTP record to access in response to the profile of the particular 
. customer. 

The continuation of the transaction flow for this exemplary transaction 
by a customer of the institution that operates computer network 1 4, is 

5 schematically shown in Figure 10. The home HTTP server 90 is operative in 
response to the customer inputting the correct PIN to send HTML documents 
to the HTML document handling portion of the software in the computer 
which operates the ATM. These messages may include information used to 
generate screens which prompt the customer to select a transaction. For 

1 0 purposes of this example, it will be assumed that the customer inputs at the 
touch screen 30 a selection which corresponds to the dispense of cash, which 
is a common transaction at an automated banking machine. 

The selection of the customer through the input device of the touch 
screen is communicated back through the HTML document handling portion 

1 5 which communicates an HTTP message to the home HTTP server 90. Server 
90 then responds by sending another HTML document to the banking machine 
which prompts the customer to select an amount. Again the customer may 
input a selection on the touch screen which indicates the amount of cash 
requested by the customer. This HTTP message passes through the HTML 

20 document handling portion and the browser 76 to the home server 90. 

In response to the receipt of amount data from the customer, the home 
server 90 is preferably operative to communicate electronically with the back 
office 94 to verify that the customer has the amount requested in their account. 
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This is preferably accomplished through a Common Gateway Interface (CGI) 
1 06 which is in operative connection with the home server 90. For purposes 
of this transaction it will be assumed that the back office 94 indicates that the 
money is available in the customer's account and sends a message through the 
CGI 1 06 to the home server 90 indicating that it may proceed. 

As schematically represented in Figure 1 1, the home server 90 then 
operates to send a document back to the HTML document handling portion in 
the ATM software. This message preferably will cause information to be 
displayed on the screen which advises the customer that the transaction is 
being processed. In addition the HTML document returned preferably 
includes JAVA script which include embedded instructions which are 
executed and communicated to a JAVA applet associated with the operation of 
the sheet dispensing mechanism 42. 

The document returned from the home server 90 may include 
advertising or other information instead of or in addition to the customer 
message. The document returned may also include an instruction which 
causes, the machine to access or generate another document. These 
instructions may invoke methods in the profile applet which depend on the 
properties associated with the customer, the machine, the current time and/or 
other circumstances. This enables accessing documents that provide 
promotional messages such as advertising or other information to the customer 
while the customer is waiting for the machine to operate. It should be 
understood that these documents may be accessed anywhere, including from 
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the Internet. This makes it possible to selectively present a wide range of 
materials to customers. It also enables operators of ATMs and other 
transaction machines to present advertising to customers, on a broad basis, or 
targeted to categories of customers or even targeted to individual customers on 

5 a segment of one basis. This could be advertising of the machine operator 
such as a bank, or advertising pertaining to virtually any type of goods or 
services. The advertising may also be selectively presented based on the 
particular transaction device being operated, the amount of funds involved or 
other parameters. The HTML documents also enable the presentation of video 

1 0 and sound to the customer which may enhance the effectiveness of 
promotions. 

The message to the JAVA applet in the device application portion 84 
of the software to initiate operation of the sheet dispenser results in generation 
of a message to the device server 92. The message to the device server 92 to 

15 dispense cash is preferably analyzed by the monitor software 102 to check to 
see if the rnessage is appropriate. For example the monitor software 102 is 
preferably operative to assure that the amount of cash being requested does not 
exceed a preset amount. It can also optionally check to verify that the amount 
provided to this customer within a prior period has not exceeded an amount. 

20 This may be done by the device server sending a message to the back office 
which includes the card data it has previously received from this customer. 
This message may pass through server 90 and its associated CGI, or other 
connection. Assuming that the dispense instruction is not prevented by a 
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message from the back office or the monitor software, the device server 92 is 
operative to send a dispense message to the device interfacing software portion 
64 in the ATM, The software portion 64 is thereafter operative responsive to 
the message to operate the sheet dispensing mechanism 42 to dispense the 
amount of cash requested by the customer. 

The monitor software 102 preferably performs additional functions in 
the device server. For example, government regulations or good business 
practice may require limiting the size and amounts of deposits which may be 
made into an ATM. This may be advisable to prevent "money laundering" or 
other suspicious activities. The monitor software preferably operates to limit 
the amount of any single deposit to below a set limit. It further operates by 
communicating with the home bank back office system 94 to prevent a series 
of deposits within a preset time from exceeding a certain limit. The monitor 
software may also work in connection with the proxy server to limit certain 
transactions that may be carried on at the banking machine responsive to 
instructions from foreign servers as later discussed. 

It should be noted that in a preferred embodiment of the invention the 
JAVA applet which is operative to send the message which causes cash to be 
dispensed, works in connection with another applet which controls the mix of 
bills dispensed to a customer. Many automated teller machines have the 
ability to dispense two or more denominations of currency bills. It is desirable 
to control the mix of bills dispensed to a customer to suit that which is 
available in the machine and to avoid running out of one denomination of bills 
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before the other. The bill mix applet is preferably operable to control the bill 
mix in accordance with the desires of the institution operating the ATM 
machine as well as is in accordance with the ATM machine's capabilities. 
Alternatively, a JAVA applet for controlling bill mix may reside in device 

5 program 70 in device interfacing software portion 64. 

As will be appreciated by those skilled in the art, the particular JAVA 
applets and/or configuration data in the machine may be selectively loaded 
from the home server 90 at machine start up or at other times. Because the 
applets and configuration data may be selectively delivered to particular 

1 0 machines, the machines may be tailored specifically to the particular ATMs 
currency dispensing and other capabilities. For example, the ATM may be 
configured so that certain applets or groups of applets must be present to 
enable the machine to operate. One approach to loading such data or 
programs is to provide address values in the terminal software to indicate 

1 5 where the needed instructions to acquire the applets or data may be obtained. 
If the applets or groups of applets are not already present in memory of the 
ATM terminal at start up, the software is operative to access the system 
addresses for the documents which contain the required records or instructions 
which will cause the machine to load the required records. The browser may 

20 be used to access the addresses and the software loads data corresponding to 
the instructions fi-om the accessed documents into a memory in the ATM 
terminal so that the terminal has the required applets and data. Such document 
addresses may be accessible through the home server 90. Alternatively the 
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addresses may be on a separate development server connected to the intranet 
16. In this way each transaction machine is able to load the applets and data 
which include the operative code it needs to operate the transaction devices in 
the machine. Alternatively, the documents may be provided through a 
development server or other server that is accessible to the machine through a 
wide area network. The documents may be provided on the development 
server to provide the machine with instructions on how to acquire the 
operating code to carry out a wide variety of functions. The instructions may 
direct the machine to acquire the necessary data and code from addresses 
accessible through HTTP servers by an HTTP client in the machine. The data 
and code can be acquired responsive to instnictions in one or several 
documents. The machine may also require that the applets loaded in this 
manner be signed applets including digital signatures or other authenticating 
features to achieve operation of certain devices in the machines. 

Alternatively, embodiments of the invention may acquire the necessary 
applets and data from a remote data store. The data store preferably includes 
the data and/or programs that enable the machine to operate as desired or have 
instructions on where the machine may acquire the necessary instructions and 
data for operation. The data may be accessible from a data base server. The 
transaction machine addresses a query to the database server. The query 
includes or is accompanied by indicia from the machine which identifies the 
machine. This may be the particular machine such as a machine number, 
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and/or may include indicia rcpresenlalive of Ihe type or fimclional device 
capabililies of Ihe machine. 

The data store preferably includes records which have the data or 
programs that are to be transmitted to the machine. In response to the query to 
the server, the server retrieves records from the data slore and responsive 
thereto delivers one or more messages to the HTTP client in the Iransaclion 
machine. This message(s) includes the configuration data or applets to enable 
the machine to operate in the manner desired or may include instructions 
which indicate how the machine is to acquire such programs from servers 
connected in the system. 

In the example shown the configuration server and data store may 
operate on the same computer as home bank server 90. In other embodiments 
the database server may reside elsewhere in the networks to which the 
machine is connected. 

An advantage of the machines and systems which employ such 
features is the flexibility to change the operation and customer interface of the 
machine to respond to changing conditions. This may include a change in a 
transaction function device. Conditions may change so that certain 
transactions are limited or are not available. For example, a machine may 
normally accept deposits but its depository is full. In that situation the 
machine may change the documents it accesses to present messages to users 
through its output devices so that the deposit option is no longer offered. This 
can be accomplished by the applets and data loaded into the machine initially. 
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which provide for inslriictions wlicn such evenl is sensed. Ahemalivcly, ihe 
niachiiic prograinniing may be modi Tied l>y loading new applets and/or dala 
fiom an HTTP server responsive lo its then current status. This may be done 
responsive to a query lo a database sei-ver which inchides or is accompanied 
by dala representative of the changed conditions or capabilities of the 
machine, hi response the server delivers the applet(s), data and/or instructions 
which will operate the machine in the modi Tied mode. 

This approach eliminates the situation with conventional transaction 
machines where the static interface presentation on output devices offers a 
transaction option to a customer. Sometimes, after the customer has made the 
selection an indication is given that the selected transactions option is not 
available. The approach described herein may be used with numerous 
transaction options and variations of transactions. Tlie transaction options can 
be readily changed from the database server on a machine by machine basis or 
even a customer by customer basis as previously discussed, based on the 
desires of the entity operating the transaction machine. 

The discussion of the exemplary transaction will now be continued. In 
response to the cash dispenser 42 dispensing the requested amount of cash, 
device interfacing software program 64 preferably operates to send a dispense 
operation message confirming the dispense back to the JAVA applet 
responsible for the dispense in the device application program 84. As 
represented in Figure 12, the particular applet is operative to update the 
transaction record 104 to indicate the dispense of currency to the customer in 
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Ihe parlicular amount. The embedded JAVA script inslruclions which were 
operative to cause the dispense of currency to the customer, also preferably 
inchide instructions to send a connrming message back to the liomc server 90 
that the dispense is complete. The receipt of the dispense operation message . 
indicating the cash was dispensed causes the JAVA applet to conrigurc the 
HTML document handling portion to send a device response message back to 
the home server. The home server then is preferably operated in accordance 
with its programming to indicate to the back office 94 that the customer 
received the amount of funds dispensed. This amount is deducted from the 
customer's account in the records maintained by the back office system. 

Generally during a transaction it is common to ask the customer if they 
wish to have a receipt for the transaction. This may be done at various times 
during the transaction flow. In the present example, after the cash has been 
dispensed the customer operating the machine is sent such a message as 
reflected in Figure 13. The home server 90 is operative to send an HTML 
document which includes a screen asking the customer if they would like a 
receipt. This message is displayed as part of a page on the touch screen 30 
responsive to receipt of the message through the browser 76. Alternatively the 
document may be generated by the machine. In response to the customer 
indicating that they do or do not want a receipt, a message is returned to the 
home server. Again it should be understood that the screens displayed to the 
customer are preferably those that the customer is accustomed to fi*om his or 
her home institution, and may be a part of his or her unique home page. 
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Assuming thai Ihe customer wishes to receive a transacUon receipt, the 
home server 90 operates as shown in Figure 14 lo send a documcnl back lo the 
ATM with embciided JAVA script indicating that a transaction receipt is to be 
printed. These instructions in JAVA script arc communicated to the device 

5 apphcation portion 84 wliich scuds a TCP/IP message tlirough the intranet to 

the device server 92. The device server 92 in turn communicates a message 
with instmctions to the device interfacing software portion 64 in the ATM. In 
response to receiving the message, software portion 64 is operative lo cause 
the printer 46 to print the customer's transaction receipt. The JAVA applet 

1 0 responsible for enabling the printer is also preferably operative lo update the 

transaction data object or record 1 04. As later discussed, the applet which 
controls the printing of the receipt may obtain the data used in printing the 
receipt from the transaction data object. 

It should be understood that even if the customer does not wish to have 

1 5 a receipt it is desirable to print a record of the transaction in hard copy through 

the journal printer 48. This may be accomplished in response to imbedded 
instructions which are part of the same document from the home server 90 
which causes the transaction receipt for the customer to be printed, or may be 
part of a separate document which indicates that the customer has declined the 

20 option to receive a transaction receipt. Alternatively, the journal printer may 
be actuated responsive to other applets such as the applet which causes the 
dispense of cash, or in another manner chosen by the operator of the ATM. As 
will be appreciated from the foregoing description the operation of the 
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"preferred embodimcnl of Ihe ATM is inherently flexible and programmable to 
meet the nccils of the system operator. 

As sluiwn iu iMgiire 1 5 upon completion of the printing of the 
transaction receipt, the software portion 64 is preferably operative to send a 
device operation message to the device server 92 which is indicative that the 
requested device function was carried out successfully. The device server 92 
is operative to send a corresponding device operation message to the device 
application portion 84, and in the preferred embodiment to the particular 
JAVA applet responsible for the printing of the receipt. The JAVA applet in 
turn configures the HTML document handling portion to generate a message 
back to the home server in the form of a device response message to indicate 
that the receipt was printed for the customer. 

Having received cash and a receipt, the customer is then prompted by a 
display screen generated from an HTML document from the home server 90, 
to indicate whether they wish to conduct another transaction. The visual page 
or screen prompting the customer in this regard is displayed on the touch 
screen 30, For purposes of this example it will be assumed that the customer 
does not want another transaction and a message to that effect is returned 
through the HTML document handling portion back to the home server 90. 

As shown schematically in Figure 1 7 in response to receiving a 
message that the customer is done, the home server 90 is operative to send a 
"go home" message to the ATM. This message preferably includes an HTML 
document which produces a screen display thanking the customer. This 
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invoculion (RMI) lo pass or deliver the object to server 90 and then 
transmitting llic data Ihrongli messages from the server to the back olTice or 
liirouglv messages or oilier techniques. 

Of course in other cmboilimcnts transaction infonnalion may be stored 
5 in a database for extended periods rather than being returned after each 

transaction, Alternatively the ATM 12 of the present invention may include 
applets which are operable to deliver transaction record infomiation lo 
addresses olher than thai of the home server, ifthal is desired by the operator 
of system 14, 

10 The operation of the computer system when a "foreign" user uses the 

ATM 12 is graphically represented with regard to Figures 19 through 24. A 
transaction with a foreign user who is not a customer of the institution that 
operates ATM 12 and computer system 14, will be operated under the control 
of the home server 90 and will proceed in the manner of the prior example 

1 5 through the point where the customer inputs their card. The customer inputs a 
card having indicia corresponding to a URL address that does not correspond 
to the home server 90. The HTML document handling portion is operative to 
configure a message addressed to access a URL address that corresponds to 
the indicia on the customer's card or other address responsive to such indicia. 

20 This message is delivered to the proxy server 88 which in turn passes the 
message to the wide area network 1 8. From the wide area network the 
message proceeds to the foreign server corresponding to the customer's URL 
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address. For piir|>oses of llus example the foreign server corresponds to server 
% which is connected to the hitcmct. 

In the preferred embodiment oftlie invention proxy server 88 inckides 
screening software graphically indicated 107. Screening software is preferably 
operable to check addresses to which messages are being directed by the ATM 
and to selectively prevent the sending of messages to particular addresses. 
This serves as a "fire wall" and is desirable for purposes of preventing fraud in 
the system. 

As shown in Figure 20, the foreign server 96 is preferably operable to 
communicate HTTP messages, including HTML documents, to the ATM 12 
back through the wide area network 18. This may be done using a secure 
socket connection ("SSC") so as to minimize the risk of interception of the 
messages. Of course other techniques, including encryption message 
techniques may be used to minimize the risk of interception of the messages. 

As schematically represented in Figure 20 the response document from 
foreign server 96 preferably includes embedded JAVA script is representative 
of or corresponds to a digital signature which identifies the foreign server 96. 
This may be accomplished by loading an HTTP record including a signed 
applet, as previously discussed. An applet in application portion 84 in the 
ATM preferably operates to verify the digital signature in the manner 
described in the prior example, and sends a message indicating that the 
transaction has been authorized. The digital identity of the foreign institution 
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will be stored in memory in the ATM and eventually recorded in the back 
office 94. 

It should be noted that the HTML documents from the foreign server 
96 produce the visual pages or screens of the foreign institution which the 
5 foreign customer is accustomed to seeing. These pages may correspond to the 
foreign user's "home page" which are tailored specifically to the needs of the 
particular user. 

Figure 21 shows an example of a document accessed through the 
foreign server 96 to the ATM 12. The document from the foreign server may 

1 0 include embedded JAVA script which enables operation of the JAVA applets 
in the manner previously discussed to operate the devices 36 in the ATM. As 
shown in Figure 21 the TCP/IP messages to the devices from the JAVA 
applets pass from the device application portion 84 to the device server 92, 
and the instructions therefrom to the device interfacing software portion 64 in 

1 5 the ATM. Device operation messages take a reverse path. As these messages 
pass through the device server 92, monitor software 102 monitors them to 
minimize the risk of fraud or abuse. 

As indicated in Figure 21, the documents from the foreign server 96 
may be operative to display at the touch screen 30 a request for the customer 

20 to input their PIN. The embedded JAVA script instructions would, as in the 
sample transaction previously discussed, include instructions that enable the 
keyboard 40 to accept the customer's PIN. As in the prior example, a 
transaction record 104 which includes a shared data object concerning this 
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Iransaclion would be opened by the device applicalion software portion. As 
previously discussed, provisions may be made lo prcvcnl Ihc passage of PIN 
data through the browser if desired. 

Figure 22 indicates the return of the device operation message and PIN 
5 data lo the JAVA applet, which in turn transmits the data back to the foreign 
server 96 through the wide area network 1 8 using the secure socket 
connection. From this point the transaction proceeds generally as previously 
described, except that the foreign server 96 sends the HTTP records, including 
HTML documents, and receives the messages from the document handling 
1 0 portion of the ATM. The foreign server 96 includes the JAVA applicalion 
software necessary to include the embedded JAVA script in the documents 
that are sent to the ATM to operate the devices 36 in the machine. 

As the foreign server 96 operates the machine, the monitor software 
1 02 in the device server 92 is operative to monitor the messages in the manner 
15 previously discussed. Such monitoring would for example, operate to prevent 
the dispense of unduly large amounts of currency out of the machine. The 
monitoring software may also operate to restrict certain foreign institutions to 
a subset of the transaction machine devices or capabilities. This is done based 
on data stored in memory which limits the devices or activities that can be 
20 carried out from documents at certain addresses. This may be achieved for 
example through the use of code plug-ins which implement a class of the 
transaction objects which limits the operations that can be performed. For 
example, the operations which enable connection to the foreign server may 
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inslantiate the objects which provide specified limited capabilities for 
messages received from the foreign server. This may for example limit the 
amount of money dispensed, prevent operation of a check acceptance device, 
limit the dispense to printed documents such as tickets, prevent operation of 
the cash dispenser or limit use of the machine in other appropriate ways. This 
may be done based on the addresses or portions of addresses for documents. 

If the capabilities of the machine to the foreign customer arc limited, 
the foreign customer may be provided with a visual interface from the foreign 
bank based on the transactions the machine can perform and that the owner of 
the machine will allow. As a result the documents accessed at the foreign 
bank server may be a variation of what the customer would be provided at a 
machine operated by the foreign bank. This could be based on documents 
specifically developed for operating foreign machines, or could be a variant of 
the usual foreign bank interface with visual indications that certain 
transactions are not available. In some instances the interface may indicate 
that some transactions are available with an associated service charge. 

The ATM of the described embodiment may enhance security by 
limiting the addresses that the browser may access. This may be done by 
maintaining a list in the memory of the machine. This list may be maintained 
in HTTP record(s) (including documents) accessible through the home bank's 
intranet. The machine may access the record periodically and update the 
memory data. This record may itself require a digital signature corresponding 
to a signature in the tenninal memory before the data will be loaded into 
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terminal memory. This informalion may also include Ihe inslmclions and 
informalion for the ATM to verify that the messages it receives by accessing 
documents on the foreign server are genuine. This may inckide digital 
signatures which when transferred using public key or private key enciyption 
techniques verify the messages as genuine. The machine checks to be sure the 
signature in the records accessed from the foreign server corresponds to the 
digital signature for that address stored in memory, and enables operation of 
transaction devices, such as the cash dispenser, only when such 
correspondence is present. Of course various approaches to verifying and 
encrypting messages may be used in various embodiments. As used herein 
signatures or signed record encompass any indicia which is included in or is 
derivable fi-om a record which is indicative that it is authorized. 

As can also be appreciated from the foregoing disclosure, the foreign 
server 96 may communicate to the user through the touch screen in a language 
that is different from that normally used by the customers of the institution 
that operates the computer system 14. As a result the HTML documents may 
display requests to dispense currency of a type or in an amount which is not 
included in the ATM. To accommodate this situation an applet is preferably 
included in the device application portion 84 to deal with requests for foreign 
currency. The foreign currency applet causes the ATM to send a message 
back to its home server for purposes of calculating a closest amount which 
may be provided to the customer in the available currency in the ATM which 
corresponds to what the customer requested. As will be appreciated, this 
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applet will be operalive to call the particular function address within the home 
server 90 that is capable of providing this function. When the dispense is 
made Ihe applet is also operalive to indicate to server 96 that the amount 
dispensed differs somewhat from the amount the customer requested. Of 
5 course in other embodiments, other approaches may be used. Alternatively an 
applet in the machine may generate visual displays that show equivalents in 
local currency when foreign currency amounts are displayed or processed. 
This may include presenting both amounts on visual displays presented to a 
user. 

1 0 As represented in Figure 23, when the foreign customer has completed 

their transactions as indicated through the touch screen 30, the foreign server 
96 is operative to send the "go home" message back to the ATM. The receipt 
of this message is operative in the manner previously described to cause the 
device application portion 84 to operate responsive to the embedded JAVA 

1 5 script instructions to configure the HTML document handling portion to cause 
the browser 76 to reestablish communication with the home server 90, or other 
designated document address. 

As indicated in Figure 24 the applet in the device application portion 
84 which processes the "go home" message is preferably operative to 

20 reconnect to the home server 90 as well as to send the transaction record 
information in record 104. This transaction record information which is 
preferably packaged in a data object, includes the customer name, the foreign 
institution name, digital identifier, amount information concerning amounts 
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dispensed, transferred or deposited, and all other pertinent transaction data. 
The transaction data is used by applets in pcrronnini; transaction steps in 
which any portion of the data is rcciuired. Al the completion of the customer's 
activity al the machine an applet provides a transaction data message which 
includes at least a portion of the collected data. This data is communicated 
from server 90 through the CGI 106 to the home bank's back office 94. This 
inlbrmation is stored in the back office for later use for puqxiscs of settlement 
with the foreign bank operating the foreign server 96. Alternatively or in 
addition, transaction data may be recorded in the terminal in memory as well 
as in hard copy on a journal printer. Transaction data may be stored for 
downloading in a batch or by passing objects including data from many 
transactions. Batch data may be communicated at times and to addresses as 
may be stored in memory in the terminal configuration data. 

An advantage of embodiments of the invention is that transaction data 
may be delivered to addresses in a local area network or in a wide area 
network such as the Internet. This facilitates conducting wide varieties of 
transactions and enables directing messages related to tracking use (such as for 
electronic purse type smart cards) or for settlement of various transaction types 
to a selected system address. 

It will be appreciated that the described embodiment of the automated 
banking machine and system of the present invention provides the advantage 
that when the machine is connected to a wide area network such as the 
Internet, customers are able to carry out their banking transactions virtually 
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anywhere in the world. Furlher, despite the broad capabilities of the system, 
because the macliine may be monitored locally, both in terms of connection 
and activity, the risk of fraud is minimized. 

Embodiments of the invention may include a further feature to 
S facilitate access to documents in the network to which the machine is 

connected. This feature is operative to detemiine if an HTTP record such as 
an HTMl- document or other item is accessible at an address for downloading 
before the computer will attempt to access the record. This avoids transaction 
time outs that might otherwise occur as a result of inability to access a record 
10 due to the server through which the record is normally accessed being down. 
Other embodiments may consider both the size of the record and the transfer 
rate and determine that a transfer speed for the record is not sufficiently rapid, 
so that an alternative record should be transferred. 

In one embodiment this feature is achieved through use of a separate 
1 5 program or applet which checks to see if a server that the computer will 
subsequently want to access is alive. The applet operates responsive to 
receiving an address or portion thereof, to which a connection will be made. 
The applet operates to make a socket connection to the address and loads a 
small but sufficient amount of the record or otherwise operates to determine 
20 that the server through which the record must be accessed is alive. In response 
to the applet verifying the operation of the remote server, or otherwise 
determining that conditions indicative that the record may be accessed or 
loaded, the computer then operates so that the browser or similar software 
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component is enabled lo navigate to the adilress at the appropriate lime in the 
transaction sequence. IT the applet is iniable to detect that the remote sei-ver is 
alive, or determines that it docs not appear the record may be successrully 
accessed or loaded, steps may be taken to access alternative addresses or to 
discontinue the transaction. Alternative addresses to access may be based on 
data stored in the memory of the terminal or may be obtained by accessing 
documents either locally or remotely which include data from which 
alternative addresses may be obtained or derived. Alternalive addresses are 
similarly checked to make a determination that the records can be accessed 
before attempts are made to access the alternative records. This approach 
avoids delays in carrying out transactions. 

Alternative embodiments may employ other approaches to determine if 
desired HTTP records such as HTML documents may be successfully 
accessed and/or dou^nloaded adequately before the browser providing the 
customer interface attempts to access the document. Such embodiments may 
consider in determining whether the document can be successfijUy accessed, 
the transfer speed or other conditions related to system operation or document 
content. For example, the applet which tests to determine that the HTTP 
record can be accessed, or a further applet, may determine the transfer rate at 
which the record can be transferred to the computer. The rate at which the 
data can be transferred may be compared to data stored in memory, and if the 
rate is slower than the data representative of the desired stored rate an 
alternative record is accessed. This may be for example an HTML document 
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Stored locally in the machine. Other embodiments may include programs 
which consider the size of the HTTP record and the transfer rate in 
determining a transfer speed. Such programs then determine if the record can 
be transferred fast enough to suit the parameters established in the 
configuration in memory, and if not, alternative addresses are accessed. Such 
alternative records may be similarly tested for transfer speed before being 
transferred. 

Programs may also consider other factors in deciding to access a 
particular address, such factors may include for example day and time 
information, or information from sensors such as sensors in a floor indicating 
that other persons are waiting to use the machine. In this way access to 
documents that have extensive outputs which may tend to prolong transactions 
can be avoided even when records can be loaded at an adequate speed. 

While the described embodiment of the automated banking machine 
and system of the present invention is shown with regard to a particular type 
of machine that is made specifically for connectibility to local or wide area 
networks, conventional automated banking machines may also be adapted to 
include such capability. Specifically the HTML document handling portion 
and device application portions may be included with other conventional 
software which operates within an automated banking machine. This enables 
such ATMs to operate either in the conventional proprietary network or as part 
of a wide area network. In addition, automated banking machines may be 
configured to operate their devices through the device interfacing software 
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porlion of the invention or through a different software interface when 
operating in a conventional network. Such machines may switch to requiring 
device messages to be passed through a device server when operating under 
the control of a server within the wide area network to maintain security 

5 within the system. In this way a single ATM could operate in proprietary 
networks in the manner of current ATMs as well as in the network 
configuration of the system of the invention. 

Alternative embodiments of the invention operate to communicate 
transaction messages used in a proprietary ATM network. This may be 

10 accomplished by using a CGI in connection with either the HTML document 
handling portion of the ATM or the HTTP home server or other server. The 
CGI operates in connection with a message conversion program and database 
to cull the necessary data from the HTML documents and response messages 
and generate the defined transaction request messages appropriate for the 

15 proprietary transaction network. Likewise, the message conversion program 
and CGI operate to receive function command messages from the proprietary 
network and convert them and generate appropriate HTML documents and/or 
TCP/IP messages for use by the ATM. Because these proprietary network 
formats are defined and the data necessary to produce and interpret the 

20 messages are known, the use of the ATM 1 2 directly in a conventional 
proprietary ATM network is achieved. 

Conventional ATM transaction messages are defined layout messages 
that do not include HTML documents on HTTP messages. An example of 
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' known conventional messages used to operate ATMs are Diebold 91X 
messages. Such messages generally involve transmission of a request 
message from an ATM in a defined layout including customer input data 
(account/pin) and an indication of the type and amount of transaction 
5 requested. The request message is received by an ATM host computer which 
sends back a response message with a defined layout which includes an 
indication whether the transaction is authorized. The ATM then returns 
another message to the host computer indicating whether the machine was able 
to carry out the transaction. The messages used in such conventional 
1 0 proprietary networks generally occupy relatively little band width. 

In connecting the ATM of the invention to such a network, a server is 
provided. The server is in operative connection with a memory which 
includes a relational database which holds the message conversion and 
document creation data. In one configuration, the server is connected to the 
1 5 document handling portion through a network, or may reside on the computer 

of the ATM. The server produces the documents which the browser accesses 
and which include the transaction device instructions. The server (or a 
connected server) communicates the conventional messages with the host. 
One server may provide an interface for several ATMs connected to it in a 
20 LAN, or alternatively, each ATM may have its own server operating therein. 

The ability of ATM 12 to communicate in a proprietary network also 
enables operation of the ATM in a manner in which the interface is generated 
by a user's home institution in the manner previously described, but in which 
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transactions are authorized through messages directed through a proprietary 
ATM network. This achieves the security of using the proprietary network 
while providing the customer with the advantages of the familiar home bank 
interface and/or "personal home page" interface. 

In such a configuration the ATM transaction function devices may be 
operated in a conventional manner in response to conventional ATM 
transaction messages such as Diebold 91X messages, in the proprietary 
network. The customer output devices, such as the screen (and speakers if 
provided) communicate through a browser connected to a local or wide area 
network. The browser accesses documents to prompt a customer through 
operation of a transaction, but the documents do not include instructions which 
cause operation of devices such as the cash dispenser. 

In one configuration the browser may be operated by the computer in 
response to the status of devices in the machine, as the devices are operated in 
response to conventional ATM messages. In this manner the browser may be 
navigated to selected addresses, including addresses which are associated with 
the customer based on customer input data. However, as the documents 
received by the browser will not operate the transaction function devices, there 
is less need for security measures in accessing documents. As a result, the 
customer may still operate the machine in response to a familiar and unique 
interface, and marketing information such as advertising or other material may 
be presented in the transaction sequence. 
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In other embodiments machines may perform some device functions 
based on conventional messages, while others may be performed in response 
to instructions in HTML documents or other HTTP messages. For example 
HTML documents may provide considerable data for use by printers or other 
5 output devices. Some embodiments may access documents v/ith instructions, 
but may ignore some and act in response to others. The approach may be 
selected by the systems operator by configuring the software based on their 
requirements. 

A further advantage of the system configuration of one preferred 
1 0 embodiment is that it has enhanced flexibility for communicating messages 
associated with the ATM. The device manager 68 preferably generates status 
messages associated with the status of devices 36. These status messages may 
commonly represent information about conditions which exist at the devices. 
Such messages may indicate that supplies of paper for printers or currency, are 
1 5 low or are depleted. Other messages may indicate that devices are not 

functioning properly. Often such messages indicate that the ATM requires 
servicing. All such types of messages are referred to herein interchangeably as 
status or fault messages. 

The device interfacing software portion 64 communicates through the 
20 intranet 1 6 using TCP/IP messages. While the messages associated with 
transactions previously described are directed to the device server 92, the 
software portion 64 may include a server and be configured to address fault 
and status messages to other addresses in the intranet or the Internet. For 
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example, such fault or status messages may be directed to a software 
application which delivers messages to a service provider. Further, fault 
messages may be selectively directed based on the nature of the fault 
indicated. For example, fault messages indicative of a need to replenish 
currency or supplies may be directed to an address in the intranet associated 
with an entity who has responsibility for replenishing supplies. Alternatively, 
fault messages which indicate a need for other types of servicing may be 
directed to an address associated with an entity who can provide the type of 
servicing required. 

Alternatively, the selective dispatching of fault messages to addresses 
in the intranet 16 may be accomplished by appropriately configuring device 
server 92. In addition, either soAware portion 64 or device server 92 may 
direct fault messages from the ATMs to a fault handling system such as to a 
computer operating Event Management System™ software available from 
Diebold, Incorporated. Such software is operative to resolve the nature of the 
fault condition and to notify appropriate personnel of the corrective action to 
be taken. 

The ATM 12 may further include a software function to assist in 
diagnosing problems and providing remedial service. As graphically 
represented in Figure 2, alternative embodiments of the ATM 12 may include 
a mini-HTTP server 109 which is in communication with the device 
interfacing software portion 64. Server 109 is configured to receive device 
status messages and to produce HTTP records including HTML documents in 
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response thereto, which provide data representative of device status to a 
diagnostic device 110 such as a hand held computer terminal. Server 109 
includes a CGI for interfacing with the device software so that a technician 
may access the information in the records accessible at the HTTP addresses 
related to status messages and input test and corrective instructions through 
diagnostic device 110. The HTTP records and/or HTML documents generated 
by server 1 09 may preferably include graphic and audio instructions indicative 
of conditions such as problems, as well as corrective action data and repair 
instnictions. 

In alternative versions of the invention the functions of the mini-HTTP 
server 109 may reside in device server 92. This may be particularly 
appropriate where the function of the device server resides on the computer in 
the ATM. Regardless of where the function resides the use of the visual and 
audio components of HTML documents associated with maintenance and 
diagnostic messages facilitates servicing of the ATM. 

These records delivered through the mini-HTTP server include 
instructions that correspond to the status or fault conditions. Such records or 
documents may be accessed locally as previously discussed, or remotely. A 
technician using a hand held computer which includes a browser or other 
software operative to access the HTTP records may access the documents 
locally for purposes of maintenance, diagnosis and servicing. In some 
situations the customer interface and browser associated therewith may be 
used to access the mini-HTTP server, or a separate browser, display and input 
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devices on the machine and intended for use servicing activity may be used. 
Alternatively, the fault and status messages may be monitored from tenninals 
at locations anywhere that are connected in the network. The mini-HTTP 
server handling status and fault messages may also be configured to send an e- 
mail or similar message to a selected address whenever a particular condition 
or group of conditions exist. 

A further advantage of this feature is that HTTP messages may also be 
sent to the mini-HTTP server to attempt to correct problems. Such messages 
may include running diagnostic tests and receiving results. It may also include 
operating devices to test or attempt to clear jams and other malfunctions. This 
can often be done from remote locations. Of course, when there is a 
significant risk of unauthorized access to the server handling default or device 
messages, appropriate security measures should be taken. 

The HTTP records which indicate the status of the transaction function 
devices may have different forms depending on the software configuration and 
the needs of the system operator. In some embodiments the device status 
information for one or more devices may be represented by indicia contained 
within a data object. The data object may be transferred to other connected 
computers to provide the status data. The transfer of the data object may be 
accomplished by remote method invocation (RMI) for example. The data in 
the transferred data object may then be used to generate message and/or 
outputs desired by the system operator. This technique may be particularly 
useful when the operator wishes to cormect the machine to an existing 



CA 02271213 1999-05-07 



68 

monitoring system and indicia included in the data object can be used to 
generate outputs or messages indicative of device status that can be processed 
by the existing system. Plug-ins may further be used to achieve 
communication between existing monitoring systems and transaction 
machines which have different types of status conditions or different types of 
message fonnats. This includes machines which have different types of 
transaction function devices and capabilities. 

The technique of transferring a data object may also be used to conduct 
testing or modification of transaction function devices. For example, indicia 
in the data object may be modified by a servicer and the object passed back to 
the machine. The software in the machine may cause the transaction function 
devices to operate or change conditions or programming in response to the 
modified data object. This may include for example clearing a fault indication 
or causing a device to operate to clear a jam or to conduct a test. The results 
of such activity may be reflected in modified indicia in the data object which 
may then be transferred to the computer in the diagnostic terminal. Of course, 
the approaches discussed herein are exemplary and other approaches will 
become apparent to those skilled in the art from the description herein. 

Figure 25 shows a schematic view of a network configuration for an 
alternative embodiment of the automated banking machine of the present 
invention. The embodiment shown in Figure 25 includes an automated 
banking machine specifically adapted for operating in connection with 
conventional automated banking machine systems such as systems which 
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operate using Diebold 91 X ATM message formats or other noivHTTP 
conventional fomiat. A host computer 120 is a conventional ATM host which 
communicates using such messages. The host communicates with an interface 
server schematically indicated 122. Interface server 122 operates in the 
5 manner previously discussed and is in operative connection with a memory 

that includes the information necessary to convert HTTP messages that pertain 
to a transaction request to a 91 X request message or other conventional 
message, which can be handled by host compiuter 120. Likewise interface 
server 122 and the instructions and data stored in memory are operative to 

1 0 convert a conventional 91X command message or other conventional 

command message from the host 120 into HTTP messages which can be used 
by the automated banking machine to carry out the command. Similarly 
interface server 1 22 is operative to receive the HTTP messages which 
correspond to the response of the automated banking machine to the 

IS commands and to produce a 91X response message or other conventional 

response message to the host. In accomplishing these functions the interface 
server communicates with a interface client 124 which in the preferred 
embodiment is a COMM plug in which operates on the banking machine 
terminal under a Windows NT® operating environment. Interface server 122 

20 also includes a command/status gateway 126. The command/status gateway is 
operative to receive command and status messages from the software portions 
handling the functional devices within the machine. The messages concerning 
the devices are used in producing transaction messages to send back to host 
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120. In addition, the command status gateway portion also produces status 
messages indicative or the status ofdevices which may also be communicateil 
to the host. 

The interface server 122, command status gateway portion 126 and 
5 interface client 124 may reside in soAware on the automated banking machine 
terminal. In this connguralion the terminal appears to the host computer to be 
a conventional machine. Alternatively interface server 122 and command 
status gateway portion 126 may reside on a separate server, while the interface 
client portion 124 may reside on the temiinal. This enables the interface 

10 server 122 to handle a number of automated banking machines by connecting 
the machines to the interface server through a network. 

The alternative configuration of the automated banking machine 
system shown in Figure 25 is particularly adapted for use in connection with 
existing ATM system. The machine includes an HTML document handling 

1 5 portion 128 which includes a browser which operates in the manner of the 

embodiments previously described. The HTML document handling portion is 
alternatively referred to as a browser herein for purposes of simplicity. The 
HTML document handling portion operates in connection with a network 130 
to access HTTP records in the form of HTML documents through servers 132, 

20 1 34 and 1 36. For purposes of this example server 1 32 will be considered the 
server of the home bank which operates the automated banking machine. The 
browser portion 128 is enabled to access documents of its home bank for 
purposes of obtaining content and instructions for purposes of outputting 
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informalion lo customers as well as for operating devices on the machine. 
Servers 134 and 136 arc represcniativc ofolher servers which the automated 
banking machine may be instructed to access for purposes of downloading 
documents which include information or instructions. Oflen such documents 
from non-home bank servers will include information which is to be presented 
to customers such as advertising/promotional material, stock quotations or 
other types of infontialion. It should be understood that the servers 1 34 and 
136 may be directly connected to network 130 or may be accessed through 
other networks and servers. In some embodiments such servers may be 
accessed through the Internet for purposes of providing documents lo the 
automated banking machine. 

Document handling portion 128 includes a terminal theater software 
portion schematically indicated 138. Terminal theater portion 138 is 
schematically shown in greater detail in Figure 26. Terminal theater portion 
138 includes a back stage frame 140 and a theater frame 142, The back stage 
frame 140 although it resides in the browser, is not visible on the screen of the 
automated banking machine. The theater frame 142 is a visible frame and 
controls what is shown to the customer. 

As schematically represented in Figure 25 the HTML document 
handling portion also includes a terminal director portion 144. The terminal 
director portion includes directors which are related instances of applets which 
are used in carrying out particular types of transactions. The terminal directors 
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generally correspond to ihe operation of the JAVA applets in the previously 
described embodiment. 

The automated banking machine of the alternative embodiment further 
includes a transaction services application (TS A) schematically indicated 146. 
The transaction services application provides security, terminal condition, 
terminal authorization and key management services within the automated 
banking machine. The transaction services application includes a function for 
communicating HTTP messages with the interface server 122. The transaction 
services application may also communicate through a network such as 
network 130 in a manner later explained. The transaction services application 
also provides a server function which enables the transaction services 
application to carry out the functions of the device server 92 in the previously 
described embodiment. 

The automated banking machine of the alternative embodiment further 
includes JAVA common device interfaces schematically indicated 148. The 
JAVA common device interfaces in the preferred embodiment are related 
instances of applets which control and coordinate the operation of the 
functional devices 150 of the machines which perform transaction functions. 
The functional devices may include devices of the types described in 
cotmection with the previous embodiment or other types of devices which 
operate to carry out a function related to a transaction. The JAVA common 
device interfaces 148 communicate with the functional devices through 
common device interfaces schematically represented 152. The common 
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device inlerfiices (CDIs) provide an inlerface lhat controls Ihe 
cleclromechanical modules in llie fiinclional devices included in the aulonnUed 
banking machine. The common device inlerfaccs are schcmalically sliown in 
connection with a diagnostic sei-ver 1 54, The diagnostic server operates in a 
5 manner similar to server 109 ofthe previously described embodiment. The 

diagnostic server 154 is useful in diagnosing status and in coirecting problems 
with the devices in the automated banking machine. 

RefeiTing again to Figure 26 the backstage frame 140 within the 
terminal theater portion 138 is a component called the backstage applet 156. 
1 0 The backstage applet 1 56 is preferably a relatively thin component. 

Instructions referred to as script included in documents accessed by the 
browser selectively cause the backstage applet to notify a terminal director 
when an action is to take place in response to the instructions included in the 
accessed document. The backstage applet also operates to request that a new 
1 5 HTML document be accessed. The backstage applet also provides access to 
the shared transaction data object previously discussed which holds 
transaction data. 

The theater frame 1 42 controls the user interface as seen by the user of 
the automated banking machine terminal. Client HTML schematically 
20 represented 1 58 in the theater frame 142 defines the identifying indicia 

associated with events sent to a director manager through the backstage applet 
and provides an interface to the director manager's public methods. The 
director manager schematically indicated 160 in Figure 26, has a class which 
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resides in the Iransaclion services application (TSA) 146 as shown. The 
ilircclor manager chiss residing in llic TSA process is operative to load the 
lenuinal directors 144 to the 1 1 TMI. document handling portion. The director 
manager also includes a backstage applet class thai resides in the backstage 

5 frame 1 40. The backstage applet class of the director manager provides an 
interface for the client HTML to make requests on the director manager. 
Instructions in HTML documents can pass events through the backstage applet 
1 56 to the di rector manager. Such events include a request to authorize a 
transaction. Such requests may also include indications that the customer has 

1 0 completed a transaction or that a document loaded by the browser includes 

instructions requesting that the session be terminated. Other events which can 
be passed through the director manager include print events. Other events 
which can be passed through the backstage applet to the director manager 
include an indication that an entry was cancelled, or other defined user events. 

1 5 In response to receiving events the director manager of the 

embodiment shown responds to instructions in documents accessed by the 
browser to perform functions which include changing the content of the 
theater frame 142. The director manager responsive to such instructions, also 
changes the active terminal director class. The director manager also caches 

20 tenninal director classes for later use or loads terminal director classes and 

HTML documents from a list of available servers. The director manager also 
provides access to the shared transaction data object holding transaction data 
for a particular transaction. The director manager also sends terminal theater 
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evenls lo ihc backslage conlrol class of the cuiTeiU Icmiinal dircclor and 
provides a screen limeoul linier. Ofcourse in other embodiments tlie terminal 
dircclor may carry out other Tunctions, 

In operation ofthe alternative embodiment shown in Figure 25 the 
terminal directors 144 in the transaction services application 146 enables 
selectively accessing documents with the HTML document handling portion 
128. The documents accessed may include instructions which are used to 
operate the automated banking machine and the functional devices thereon. 
The transaction services application 146 is further operative to communicate 
the HTTP messages which are passed to the interface server 122 and which are 
used to generate conventional ATM messages which can be handled by the 
host 120. The dispensing of currency and other transfers of value are carried 
out in response lo approval from the host 120, while the interface and other 
functions are controlled through instructions in documents accessed through 
the browser. 

In one preferred embodiment the ATM or other transaction machine 
communicates with the conventional ATM host by passing the transaction data 
object between the computer in the ATM and the interface server. This 
transfer is preferably accomplished by the remote message invocation (RMI) 
feature of software such as JAVA. Of course other methods for transferring 
the data object file using HTTP may be used. 

As previously discussed, the transaction data object holds transaction 
data. The machine acquires data pertinent to the transaction such as account 
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data from a card, a cuslomcr's PIN number, requested transaclion(s) and 
amoiinl(s), ami includes this data among the transaction data. 

Once the data nccdcil to generate a conventional ATM transaction 
message is represented in the transaction data, the data object is transfcncd to 
the inlcrfiicc server. The interface sei-ver is in operative connection with a 
database 123 or other item holding conversion data as schematically indicated. 
The conversion data is used by the sofiware associated with the server lo 
generate a conventional ATM transaction request message to the host 120. 
The conventional message may be formatted as a conventional 91X message 
or other conventional non-HTTP transaction message. 

After processing the host 120 responds with a conventional response 
message. The components of the response message are received at the server 
and processed responsive to the conversion data to produce modified 
transaction data in the data object. This modified transaction data preferably 
includes data indicative of whether the requested transaction is authorized or 
denied, as well as other data. For example, if the transaction is denied it may 
include data which is indicative of the reason for the denial. 

The transaction data object with the modified transaction data is then 
transferred to the computer operating the ATM by RMI or other transfer 
method. The transaction services application 146 operating in software 
receives the data object and operates the transaction function devices 
responsive to the modified transaction data. The transaction data object has 
the transaction data therein further modified by the inclusion of information 
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concerning opcmlion oflhc devices. Afler the devices have operalcd, the 
transaction data oliject with the lurther niodillcd transaction ilata is passed 
liack to the interface server 122. The modified tninsaclion data is then used to 
generate a message to the ATM liost. Tlie message to the liosl includes data 
corresponding to the modified transaction data. Usually this message is a 
conventional non-I ITTP completion message indicating whether the 
transaction was successfully cairieil out by the transaction function devices. 

The format of the non-HTTP conventional transaction messages may 
be readily changed in the described embodiment. This can be achieved 
through the use of plug-ins. The plug-ins are operative to put data into, and to 
extract data from, the transaction data object. The plug-ins achieves 
conversion between the transaction data and desired conventional non-HTTP 
messages. The use of plug-ins enables more readily using the ATM of the 
described embodiment in connection with varied types of conventional 
transaction networks. 

Transaction data in the transaction data object is also preferably 
operative to have the computer operate the browser to access selected HTML 
documents. This may be done to indicate that the transaction is authorized or 
denied, as well as to access specific documents responsive to components of 
the message. For example, customers of banks other than the one operating 
the ATM may be given certain promotions not presented to the bank's existing 
customers. The transaction data indicative of why a transaction is denied can 
be used to access documents which provide an explanation, or can encourage 
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llic Cdslomcr to take otiicr action, such as to take u casli advance on a credit 
canl or to apply Ibr a loan. 

Tlie system schematically shown in Figure 25 is an example ofan 
automated banking nuicliine system that achieves the wide variety oi^ interface 

5 options available through the use ofan HTML interface while preserving 
compatibility with existing banking machine systems and the security 
techniques associated therewith. Of course in other embodiments alternative 
approaches and configurations may be used. 

A further advantage incorporated into the system schematically 

10 represented in Figure 25 is the ability to operate the software components of 
the described embodiment of the present invention in existing automated 
banking machines. As will be appreciated, the handling of HTML documents 
in conventional computers requires inputs through a QWERTY type keyboard 
as well as mouse clicks in locations corresponding to icons or other features 

15 on HTML documents to successfully navigate and use such documents. 

Conventional automated banking machines generally do not include a mouse 
or full keyboard. Rather conventional automated banking machines generally 
include an alphanumeric keypad similar to that used on telephones, as well as 
function keys. Embodiments of the present invention enable the operation of 

20 the system with terminals which have such interfaces operate in a manner 
which attains benefits of the invention. 

Figure 27 shows an example of a conventional automated banking 
machine interface 162. Interface 162 includes an output device which 
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incUules ii screen 164. Screen I ()4 may be a CRT, LCD or olher convenlional 
ilisplay screen. In the enUKnlimcnl sliown screen 164 is nol a touch screen as 
in the previously ilescribed embotlimenl. A plurality of function keys 166 arc 
disposed at U)cations adjacent to the screen 164. A keypad 168 is also 
included in the inlerface 162. Keypad 168 includes alphanumeric keys as well 
as certain other dedicateil keys such as "cancel", ^'correct" and "ok'\ Other 
keys on the keypad are generally blank bul in some instances may be used. 

In the operation of a conventional automated banking machine, screen 
data which is generated from information stored in the terminal memory 
produces defined transaction screens which are presented graphically on the 
screen 164. The screens appear in a sequence in response to the transaction 
function selected by the customer. Conventional screens also generally 
include text or graphics representative of selections that can be made by a 
customer. These text or graphic options generally includes lines or other 
indicia which extend to the edges of the screen adjacent to one of the function 
keys 166. A user is enabled to select the options by pressing the function key 
which is pointed to by the selection. Likewise in the operation of the 
automated banking machine a user is enabled to input the alphanumeric 
characters which comprise the PIN number as well as numeric amount 
information and other instructions by pressing the keys in the keypad 168. 

In one embodiment of the present invention the software operated in 
the automated banking machine operates to convert standard ATM key inputs 
to operating system events such as a mouse click in a desired location or an 
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inpiil IVoni a QWliK TY lypc kcyhoaril. TUc sollwurc components wliicli 
enable carrying oiil Ihis function arc sliown in !• igure 28-30. These lunctions 
Inclmle a keypad applet 170. The keypad applet 170 in the ilescribed 
embodiment is included among the applets in the terminal directors 144. The 
keypad applet 170 supports a subset of the keyboard common device interface 
(CD!) functionality. 

The keypad applet 170 coordinates with a keyboard command server 
which operates in the transaction services application 146. The server in the 
transaction services application communicates with the common device 
interface for the keypad and function keys, schematically indicated 172. The 
key CDI in the preferred embodiment is a JAVA program which is referred to 
as a wrapper for the common device interface associated with the function 
keys and the keypad. 

The software further includes a keyboard mapper program 
schematically indicated 1 74. The keyboard mapper in the preferred 
embodiment is in connection with a database 176 which stores a plurality of 
map sets. In the preferred embodiment the keyboard mapper is an extension 
of the keyboard class of objects used for operating the keyboard. The 
keyboard mapper operates to store sets of keymaps in the database 1 76. This 
is accomplished by reading information in a configuration database for the 
ATM to obtain the keymaps that are operated in the particular machine. 
During operation, the keyboard mapper selects one of the keymaps as the 
current set. This is done in response to the keypad applet and is based on 
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mapper may select keymaps responsive to inslriictions in HTML dociimcnls 
' loaded ihrough the browser. The keyboard mapper is also operative to enable 
the keyjiad and function keys appropriate for Ihe particular mapsct selected. 
5 The keyboard mapper is furlhcr operative responsive to the selected mapset to 
translate a keypad input signal or a function key input signal into a respective 
keyboard or mouse input signal which is then delivered to the keyboard input 
stream or the mouse input stream of the operating system of the computer in 
which the software operates. 
10 In the preferred embodiment the mapsets are each comprised of hash 

tables. Keymap objects are stored as values in the hash tables such that each 
object includes the values and operations necessary to convert any appropriate 
ATM key event to an operating system input event. 

As can be appreciated in the case of function keys adjacent to the ATM 
1 5 screen it may be desirable to provide a mouse input to the mouse input stream 

that corresponds to a particular coordinate location for the mouse input. This 
is provided by the keyboard mapper using the selected keymap set. The 
various keymap sets enable the different function keys to provide different 
types of inputs to the computer operating system responsive to the HTML 
20 document displayed on the browser. Further the keyboard mapper causes the 
pressing of a selected key to produce an input corresponding to a mouse click 
at a selected x,y coordinate position on the screen. It should be understood 
that either keypad keys or function keys can be used to produce mouse inputs. 
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Likewise function key inputs may be converted lo keyboard inputs. In some 
enibodimcnls however it will be desirable lo disable the mouse indicator on 
the screen sucli that the user does not notice a usual mouse icon. Such 
disabling may include in some embodiments reducing the si^c of the mouse 
icon such that it is so small that it cannot be readily seen by a user of the 
machine. 

During portions of some transactions it may be unnecessary for this 
user to press any keys. In such situations some preferred embodiments of the 
invention operate to disable the keypad keys and/or function keys. Because 
resources of the computer are used in polling siich keys for inputs, the 
cessation of such polling during appropriate times enables the computer 
resources to be devoted to carrying out other functions. This will increase the 
speed at which other activities may be carried out. This may be accomplished 
in some embodiments by the keypad applet operating to remove the key 
devices from a poll list. 

Figures 28-30 include schematic depictions of examples of the 
operation of the keyboard mapper and the keypad applet. Figure 29 shows an 
example of an input to the keypad 1 68. In this example the keypad applet 1 70 
generally in response to instructions in an HTTP record such as an HTML 
document or other events, transmits and enables events to the transaction 
services application 146. In response a mapset is selected from the database 
176 corresponding to the particular map name. The keyboard command server 
is further operative to enable the appropriate keys of the ATM. 
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In this example, in response the customer pressing the "OK" key on 
the keypad the CDI generates an appropriate signal to the transaction services 
application. As will be noted from Figure 27 a "OK" key is referred to by 
convention as the "J" key of the ATM interface. The transaction services 
application transmits the signal generated from the pressing of the "J" key by 
ihe customer to the keyboard mapper 174. In response to receiving the signal, 
the keyboard mapper operates to resolve the object in the mapset 
corresponding to the map name which will convert the function key input 
signal to a keyboard input signal which is recognized by the operating system. 
By calling the selected object from the mapset, a keyboard input signal is 
produced and delivered into the keyboard stream of the computer. This is 
represented by keyboard stream 178. In the embodiment shown the keyboard 
stream is an input to the Windows NT® operating system. The keypad applet 
170 operates to sense the input through its corresponding key listener. Applet 
170 is also operative to receive the event and may operate to display an icon or 
other graphic corresponding to what the customer has input. 

Figure 28 shows operation of the keyboard mapper in situations where 
the transaction services application operates to prevent transmitting the data 
input by the customer to the applet 170. This may be desirable for example, in 
situations where the input by the customer is the customer's PIN or other data 
which is not to be displayed. In these circumstances the transaction services 
application 146 operates to hold the data input by the customer and to send 
only a signal representative of a holding character, in this case a "*" symbol 
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back to the browser. This is done selectively in response to the instructions 
contained in documents accessed by the browser or in other HTTP records 
accessed by the computer which indicates that the input by the customer 
corresponds to their PIN or other data which is not to be sent to the browser. 
In the example shown in Figure 28 only the holding character is passed 
through the keyboard mapper to the browser. In situations where the HTTP 
record accessed invokes methods in which numerical values are to be sent to 
the browser and/or displayed on the screen (such as the amount of a 
withdrawal transaction) the signal sent by the transaction services application 
to the browser is indicative of the numerical value associated with the key 
pressed. 

Figure 30 is a ftirther example of the operation of the keyboard mapper 
in this case the input corresponds to a function key 1 66. In this case the input 
is caused by pressing the function key "A" which is shown adjacent to the 
upper right hand comer of the screen as shown in Figure 27. The signal 
generated in response to pressing the function key is passed to the keyboard 
mapper which in response to the data obtained from the data store 176 outputs 
a mouse input corresponding to a mouse click. The mouse input includes data 
representative of the x and y coordinates on the screen where the mouse click 
is to be provided. This mouse input signal is passed to the mouse stream input 
schematically represented 180. 

As will be appreciated to enable the automated banking machine which 
processes HTML documents to operate using a conventional ATM interface 
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the mouse input will generally include coordinate locations which correspond 
to a location on the screen adjacent to the particular fiinction key. This is 
because the icon, line, text or other indicia which the customer is selecting by 
pressing the key will preferably appear or extend on the screen adjacent to the 

5 key. In this way the customer is aware through the visual presentation what 
key to press to make a corresponding selection. A number of function keys 
adjacent to the screen may be operative at any one time. The customer may 
make selections by pressing a function key at one location and then a function 
key at another location disposed from the first location. This will result in 

1 0 signals being sent to the mouse stream corresponding to mouse clicks at 
coordinates on the screen adjacent to the function buttons pressed by the 
customer. During transactions various combinations of function and keypad 
keys may be operative and mapped to various keyboard and mouse inputs as 
determined by the selected mapsets. In addition developers may develop 

1 5 special mapsets corresponding to the particular graphics in HTML documents 
which are displayed. 

In the foregoing manner keypad inputs to a conventional ATM or other 
automated banking machine keypad can be translated into conventional 
keyboard or mouse inputs which can be identified and processed in a 

20 conventional keyboard input stream or mouse input stream to a computer. 
Likewise function keys may be translated into mouse inputs at selected 
locations and delivered into the mouse input stream for processing by the 
computer or may be converted into keyboard inputs and delivered to the 
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keyboard input stream. A further advantage of the described teminal 
configuration is that keys may be selectively disabled except when they are 
needed. This may reduce instances of attempts to improperly access the 
machine by pressing keys on the keyboard. Further as previously discussed 
steps may also be taken to disable keys when they are not needed to increase 
transaction processing speeds. 

A further advantage of embodiments of the present invention is the 
ability of the automated banking machine to provide printed documents based 
on instructions in HTML documents. Such printed items may include tickets, 
travelers checks, money orders, bank checks, scrip or other types of 
documents. The ability of preferred embodiments to access and process 
HTML documents enables the printing of graphics and other indicia which can 
produce printed documents having selected appearance features and selected 
ornamental designs. This can reduce the need to utilize preprinted forms and 
also enables the printing of a greater variety of printed formats. Further the 
configuration of some embodiments of the machine enable printing only 
selected portions of transaction information for record keeping purposes 
within the machine while providing versions including enhanced graphics or 
other attractive features to customers. 

Figure 3 1 is a schematic representation of the operation of the system 
in printing forms using a printer in an automated transaction machine. The 
preferred form of the invention uses the WIN32 printer services which operate 
under Windows NT® 4.0. In the exemplary transaction shown, the director 
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manager class 180 operating in the terminal theater portion 138 initiates a print 
receipt transaction by requesting a printer director 182 to print a receipt. The 
printer director in one preferred embodiment is a collection of instances of 
related JAVA beans which operate to cany out printing activities, and is one 
of the directors among the terminal directors 144. The printer director 
includes a print class which is schematically shown separately which is 
operative to invoke a print URL method. The printer class in the preferred 
embodiment includes access to the shared transaction data object which 
includes the customer specific infomiation concerning the transaction that 
includes indicia representative of information to be printed. In the case of an 
automated banking machine this may include for example indicia 
representative information which is read from a customer's card input to the 
machine and read by a card reader. This would include for example the 
customer's name and account number. The other transaction information may 
include the types of transactions conducted such as a deposit, withdrawal or 
inquiry as well as the amount involved in each respective transaction. 

The transaction services application 146 receives the print request and 
passes the URL string to the WIN printer object 1 84 by the print URL method. 
The URL address in one preferred embodiment is the address of an HTTP 
record such as an HTML document that will be used to format the document 
to be printed, in this case a receipt. This HTML document contains the 
embedded JAVA script that processes transaction data from the transaction 
data object. The URL address of the document may be on a local machine or 
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may be retrieved from another server such as through a network schematically 
indicated 1 86. Network 1 86 may be a local area network or a wide area 
network depending on the configuration of the machine. 

The WIN printer object 1 84 next navigates to the address of the 
document to be accessed. This is done in the preferred embodiment using 
Microsoft's C Web Browser2 ActiveX control. When the HTML document 
has been loaded the ActiveX control automatically begins processing the 
content of the accessed document. The transaction services application 146 
invokes the print URL method of the WIN printer object 1 84. The WIN 
printer object uses the ActiveX control to print the current HTML document. 
This printing is processed by the Windows NT® print spool and graphics 
components. 

The JAVA CDI receives an event from the print monitor component 
192 that indicates the completion of print spooling. This indicates that a file is 
now available to be read and sent to the common device interface (CDI) 188 
of the receipt printer. 

Next a printer object 190 invokes a read data fiinction in the print 
monitor 192 to determine the location and size of the print data file. The print 
object 190 sends the data or the path name of the data file to the printer CDI 
188, The printer CDI 188 then passes the print data to the printer hardware. 
This results in printing of the document. 

Once the receipt is printed the applet from the printer director 182 
issues a request to deliver the printed receipt. The delivery request is passed 
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through the transaction services application 146 to the printer object 190. The 
printer object 190 invokes the deliver method on the printer GDI 1 88 to cause 
the receipt to be delivered to the user of the machine. The operation of the 
software components enables selectively accessing document formats as well 
as using instructions contained in the documents to include transaction data 
within the printed documents. This enables producing documents of varied 
types. In addition it enables providing printing different types of documents 
for different customers. This may be desirable when providing maiketing 
information, coupons or similar indicia on transaction receipts. This approach 
fiirther simplifies providing printed formats in various languages by 
developing HTML documents which provide printed forms in different 
languages. In addition the methods of the present invention may be used for 
providing marketing to customers by profile or types of customer categories, 
as well as on a segment of one basis. 

While the printing method previously described is discussed in 
connection with delivering transaction receipts, similar methods may be 
invoked for the printing of statements for customers as well as for printing a 
transaction journal within the automated banking machine. Further by 
accessing selected documents controlling the format of printing the 
information journal records may be provided with consolidated information in 
a manner which enables conserving journal paper v^nthin the machine by not 
printing promotional or other types of infomiation that is provided on 
customer documents. 
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The printing method of the present invention also enables printing 
various types of optical indicia such as bar code or other types of machine 
readable indicia which can be used for printing coupons, checks or similar 
articles. Such coding may facilitate tracking the use of such items by 
customers for purposes of evaluating the effectiveness of various marketing 
efforts. In addition machine readable indicia may be used for printing on 
items such as deposit envelopes and/or in transaction journals. Such printing 
may facilitate reading such items by machine to verify the contents of 
deposits. 

The printing capabilities achieved through the methods of the present 
invention also enables the printing of selected graphical materials. This may 
include for example materials which include imbedded digital signatures 
which can be used to verify the genuineness of the items printed. This may be 
particularly useful for example in situations where the transaction machine is 
used to print scrip, travelers checks, betting slips or other items having 
independent value. In addition printed documents in full color may be 
produced by including a color printer in the transaction machine. 

Computer software used in operating the automated transaction 
machines of the present invention and connected computers may be loaded 
from articles of various types into the respective computers. Such computer 
software may be included on and loaded from one or more articles such as 
diskettes or compact disks. Such software may also be included on articles 
such as hard disk drives, tapes or ready only memory devices. Other articles 
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which include data representative of the instructions for operating computers 
in the manner described herein are suitable for use in achieving operation of 
transaction machines and systems in accordance with embodiments of the 
present invention. 

The exemplary embodiments of the automated banking machines and 
systems described herein have been described with reference to particular 
software components and features. Other embodiments of the invention may 
include other or different software components which provide similar 
functionality. 

Thus the new automated banking machine and system of the present 
invention achieves the above stated objectives, eliminates difficulties 
encountered in the use of prior devices and systems, solves problems and 
attains the desirable results described herein. 

In the foregoing description certain terms have been used for brevity, 
clarity and understanding. However no unnecessary limitations are to be 
implied therefrom because such terms are for descriptive purposes and are 
intended to be broadly construed. Moreover the descriptions and illustrations 
herein are by way of examples and the invention is not limited to the details 
shown and described. 

In the following claims any feature described as a means for 
performing a function shall be construed as encompassing any means capable 
of performing the recited function and shall not be deemed limited to the 
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particular means shown in the foregoing description or mere equivalents 
thereof. 

Having described the features, discoveries and principles of the 
invention, the manner in which it is constructed and operated and the 
advantages and useful results attained; the new and useful structures, devices, 
elements, arrangements, parts, combinations, systems, equipment, operations, 
methods, processes and relationships are set forth in the appended claims. 
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D 1077+2 

CLAIMS 

We claim: 

1 . Apparatus comprising: 

an automated transaction machine including: 

at least one type of transaction function device, wherein 
the type transaction function device is selectively 
operative to carry out a transaction function; 

a computer, wherein the computer is in operative 
connection with the transaction function device; 

software executable in the computer, wherein the 
software includes a browser, wherein the computer 
operates the browser to access an HTML document 
responsive to the type of Ihc transaction function device 
in the machine. 

2. The apparatus according lo cUiim 1 wherein llie machine 
includes a plurality of types of iransaclion funclion devices, and wherein tlic 
computer operates the browser to access liic documcul by generating an 
address and wherein at least a portion of tlic address is indicative of at least 
one of the types of transaction function devices included in the machine. 
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3. The apparatus according to claim 1 wherein the type transaction 
function device includes a depository. 

4. The apparatus according to claim 1 and further comprising a 
server, wherein the server is operative to deliver at least one document to the 
browser, wherein the document is delivered responsive to the one type of 
transaction function device in the machine. 

5. The apparatus according to claim 4 wherein the transaction 
function device in the machine includes a sheet dispenser, and wherein the 
machine does not include a depository for carrying out deposit transactions, 
arid wherein the one document delivered by the server includes no reference to 
a deposit transaction. 

6. The apparatus according to claim 4 wherein the transaction 
function devices in the machine include a sheet dispenser for carrying out a 
dispense transaction and a depository for carrying out deposit transactions, and 
wherein the one document the server is operative to deliver to the browser 
includes a reference to both a dispense transaction and a deposit transaction. 

7. Apparatus comprising: 

an automated transaction maclunc including: 

a pUn ality of types of transaction (unclion devices, 
wherein eacii type of transaction function device is 
selectively operative to carry out a transaction function; 

at least one output device, wherein an output device is 
selectively operative to provide user outputs; 
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a computer, wherein the computer is in operative 
connection with a memory, the output device and each 
of the transaction function devices, and wherein the 
memory includes device data representative of a 
plurality of transaction function devices in the machine; 

software executable in the computer, wherein the 
software includes a browser; 

a server in operative connection with the computer, and a 
plurality of HTML documents deliverable through the server; 

wherein the computer is operative to communicate data 
representative of the device data to the server and wherein the 
server is operative responsive to receipt of the device data to 
deliver at least one HTML document to the browser for 
processing wherein the computer is operative responsive to the 
one HTML document to operate the output device. 

8. The apparatus according to claim 7 wherein the one document 
includes instructions to operate at least one device, and wherein Ihc conipulcr 
is operative responsive to the one document to operate the device. 

9. The apparatus according to claim 7 and further comprising 
server soHwarc in operative connection with Ihc server, wherein the server 
software is operative to generate the one document responsive to the receipt of 
the data representative of the device data. 

1 0. A method comprising the steps of: 
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providing a plurality of HTML documents, wherein each of the 
documents is accessible through a server, wherein a first 
document includes a first reference, wherein the first reference 
is to a first transaction type carried out by a first transaction 
function device, and wherein a second document is accessible 
through the server and includes a second reference, wlierein the 
second reference is to a second transaction type carried out by a 
second transaction function device; and 

accessing with a browser operating in a computer in an 
automated transaction machine, either the first or the second 
document wherein the first document is accessed when the 
machine includes the first transaction function device but not 
the second transaction function device, and wherein the second 
document is accessed when the machine includes both the first 
and the second transaction function devices. 

1 1 . The method according to claim 1 0 wherein the accessing step 
includes accessing tiie first document at a first address, or accessing the second 
document at a second address. 

1 2. The method according to claim 1 0 and prior to the providing 
20 step further comprising the step of delivering to the server from the machine 

device data representative of the transaction function devices included in the 
machine, wherein the document accessed in the accessing step is accessed 
responsive to the device data. 
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ABSTRACT 

An automated banking machine (12) is operative to conduct 
transactions in response to HTML documents and TCP/IP messages 
exchanged with a local computer system (14) through an intranet (16), as well 
as in response to messages exchanged with foreign servers (20, 22, 24, 26, 28, 
96) in a wide area network (18). The banking machine includes a computer 
(34) having an HTML document handling portion (76, 80. 82). The HTML 
document handling portion is operative to communicate through a proxy 
server (88), with a home HTTP server (90) in the intranet or the foreign 
servers in the wide area network. The computer further includes a device 
application portion (84) which interfaces with the HTML document handling 
portion and dispatches messages to operate devices (36) in the automated 
banking machine. The devices include a sheet dispenser mechanism (42) 
which dispenses currency as well as other transaction devices. The device 
application portion communicates with a device interfacing software portion 
(64) in the banking machine through a device server (92) in the intranet. The 
device server maintains local control over the devices in the banking machine 
including the sheet dispenser. The banking machine operates to read indicia 
on the user's card corresponding to a system address. The computer is 
operative to connect the banking machine to the home or foreign server 
corresponding to the system address, which connected server operates the 
banking machine until the completion of transactions by the user. 
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